What are the key components of an Agentic AI system?

What you need to know

The core, which makes it an agent

• Goal and definition of done. What a finished task looks like, ideally checkable in code.
• Model. The decision-maker. Often two or more: a small, cheap model for routing and a strong one for hard reasoning.
• System prompt. Role, scope, tool-use rules, output format, and safety rules.
• Tools. Functions with a name, description and JSON Schema for arguments, plus the code that runs them. Today tools are often exposed through MCP (Model Context Protocol), an open standard for connecting models to tools and data.
• Memory. Short-term: the working context of this task. Long-term: facts and past episodes stored in a database.
• Control loop (orchestrator). The code that calls the model, runs the tool it asked for, appends the result, and repeats.

The production layer, which makes it safe to ship

• Guardrails. Input checks, output validation, tool allowlists, and human approval on risky actions.
• Budgets. Maximum steps, wall-clock timeout, and maximum spend per task.
• Observability. A trace per run with a span for each model call and tool call, tokens and cost.
• Evaluation. A golden set of real tasks, scored on every change.

1. Receive goal — load the task, the user's identity and permissions.
2. Think — the model reads the context and picks the next action.
3. Act — code validates the tool arguments, checks permissions, runs the tool.
4. Observe — the result is trimmed and added to context.
5. Check limits — stop if done, or if steps, time or spend run out.

Why budgets are a component, not an afterthought

Put numbers on a run. Say the system prompt and tool definitions are 6,000 tokens, and each step adds about 1,800 tokens (tool result plus the model's output). The context is re-sent every step, so a 12-step run reads about 190,000 input tokens. At an assumed $3 per million input tokens and $15 per million output tokens, that is about $0.63 per run, against about $0.03 for a single call. A run that loops to 40 steps costs several times more. Only a hard limit in code stops that.

A real-life example

A travel-booking agent for a corporate travel desk, mapped to the components:

• Goal: "Book Priya's Bengaluru to Delhi trip for the 14th to 16th, within policy." Done means flight and hotel confirmed and the itinerary emailed.
• Model: a small model classifies the request; a stronger model plans the booking.
• Tools: search_flights, search_hotels, get_travel_policy, hold_booking, confirm_booking.
• Memory: short-term holds the search results; long-term knows Priya prefers aisle seats and a hotel near the Gurugram office.
• Guardrails: confirm_booking needs manager approval if the fare is over the policy cap of Rs 12,000.
• Budgets: 15 steps, 90 seconds, Rs 20 of model spend.
• Observability and eval: every run is traced; 150 past requests form the test set.

Follow-up questions to expect

• "Which component fails most often?" — Usually the tools: vague descriptions, overlapping tools, and huge results that flood the context. The model gets blamed for tool-design problems.
• "Where does MCP fit?" — In the tool layer. It standardises how an agent discovers and calls tools and data from separate servers, so one integration works across many agent hosts.
• "Is memory always needed?" — Short-term, yes. Long-term only when past sessions actually improve future ones; otherwise it adds cost and privacy risk.