Agentic Systems
Agentic AI
What makes it an agent is agency — the ability to act on its own.
Ask a plain language model “what's 47 times 89, plus 12?” and it does one thing: it predicts the most likely next tokens given the question, the same next-token-by-next-token process covered in Understanding Transformers. If it hasn't memorized the arithmetic pattern well enough, it just guesses wrong — there's no way for it to double-check, look anything up, or do anything besides emit text once and stop. What turns it into an agent isn't a different model. It's agency: the ability to decide what to do next on its own and act on that decision, repeatedly, without a person approving each step. Reasoning is how it decides. Tools are how it acts. Put both around the same model in a loop, and a one-shot text generator becomes something that can work toward a goal by itself.
Nothing about the model itself changes to make this possible. It's still only ever predicting the next token. What's different is what it's predicting into: a running transcript that includes not just the user's question, but the agent's own past reasoning and the results of anything it's already tried.
Tools: how a model reaches outside itself
A language model can only produce text — it can't run code, query a database, or send a request on its own. A tool is any external function the program running the model is willing to call on its behalf, when the model asks for it in a recognizable format. Here's a full transcript of an agent solving that arithmetic question with a calculator tool:
User: What is 47 times 89, plus 12?
Thought: I need to multiply, then add. I'll use the calculator.
Action: calculator
Action Input: 47 * 89 + 12
Observation: 4195
Thought: I now have the answer.
Final Answer: 4195
Every line above, including Action: calculator, is still just the model predicting text — the same mechanism as any other generation. The new part is what happens around it: the surrounding program watches the output for a line starting with Action:, stops the model there, actually runs calculator("47 * 89 + 12") in real Python, and appends the real result back onto the transcript as Observation: before asking the model to continue. The model never executes anything itself. It only ever predicts what text should come next; the wrapping program decides which of that text is a request it should actually fulfill, and feeds the real answer back in.
Final Answer: and stop. The same loop handles a one-step question and a twelve-step one; only the number of trips around it changes.More than one agent
Nothing about the loop above requires exactly one model in play. A common next step is a supervisor: an LLM call whose only job is reading the current state of a conversation and deciding which of several specialized agents should act next — or whether none of them have anything useful to add, in which case it ends the round. Each agent it routes to can have its own system prompt, its own tools, even its own private data it's allowed to draw on that the others can't see.
This site's own Roundtable project is a live example: three personas, each an expert in a different fictional universe, sit around the same conversation. A supervisor node decides who speaks next each round, sometimes one persona, sometimes several, sometimes none. Each persona retrieves from its own private trove of lore before replying — the same tool-calling pattern above, just with a vector search instead of a calculator.
Frameworks: who builds the plumbing
Hand-rolling the loop above works, but it gets repetitive fast once there's more than one agent: routing between them, retrying a tool call the model formatted wrong, keeping track of whose turn it is, streaming partial output back to a user while all of this happens. A handful of frameworks exist to handle that plumbing so it doesn't get rewritten from scratch for every project:
- LangGraph models the whole thing as an explicit graph — each agent, tool call, or routing decision is a node, and edges control what runs next. Its supervisor pattern is what Roundtable is built on.
- AutoGen, from Microsoft, was an early and widely used framework built around agents taking turns in a shared “group chat.” It entered maintenance mode in October 2025, part of a broader move away from that pattern toward explicit graph- or workflow-based orchestration.
- CrewAI organizes agents into a “crew” with defined roles, each handed a bounded task and expected to return a result — a good fit for delegating a piece of work, less suited to open-ended, repeated turn-taking.
- Google's Agent Development Kit (ADK) is Google's own toolkit, with the deepest built-in support for Agent2Agent (A2A), a protocol for agents hosted as separate services to discover and call each other.
- Microsoft Agent Framework is Microsoft's newer successor to AutoGen, aimed at production deployment inside Azure.
All of them are solving the same problem this page just built by hand: a reasoning loop, tools to call, and, once there's more than one agent, a way to decide who acts next. They mostly differ in how explicitly they model that control flow and which cloud ecosystem they're built to fit into, not in the underlying idea.
The transcript format, the tool call, the loop that feeds an observation back in — every piece of this is small enough to write and run yourself: