What Does an Agent Framework Actually Frame?

1. Start With An Expense Assistant That Has Only A Model And Tools

The first version of an internal expense assistant is easy to demo. Give a model instructions plus three functions: read an invoice, look up policy, and write a decision. One user uploads a file, the model checks the amount, and the demo appears to work.

The second user exposes the missing system. Their histories mix. A high-value write reaches the expense database without manager approval. A browser refresh loses progress. A service restart writes the same invoice twice. The model can reason and the tools can run, but the product still lacks a stable way to operate.

2. What An Agent Framework Is

An agent framework turns the shared runtime responsibilities needed to let a model reason repeatedly, call tools, and finish work safely into reusable components and rules. It does not think for the model or choose company policy. It makes reasoning and action continuous, governable, and recoverable.

Ignore framework names for a moment. The expense assistant gradually needs six responsibilities:

• Advance the task: decide whether a model answer ends the run or requests another tool step.
• Execute tools: validate arguments before touching files, databases, or remote services.
• Keep progress: preserve users, messages, tool results, and task state for the next turn.
• Stop risky effects: allow harmless reads while pausing high-value writes for approval.
• Control the route: run independent checks together, but delay the final write until both finish.
• Connect a product: stream progress to a UI, isolate users, and resume after interruption.

Later sections call these the model loop, tool runtime, state ledger, permission gate, workflow graph, and service plane. For now, understand the problem each one solves; the names can wait.

3. How One Expense Claim Reaches Completion

1. The product receives the user, invoice, and claim id, then opens that user's session.
2. The runtime gives the model the current question, necessary history, and available tools.
3. The tool layer validates a file read, returns the amount, records it, and lets the model request policy.
4. If the amount crosses a threshold, the permission gate pauses the write and the UI shows an approval wait.
5. After approval, the workflow allows the expense write and records the external effect.
6. The answer, tool results, and task status persist so a refresh or service restart can resume safely.

This six-step route is the spine of the series. Frameworks differ less by whether a class exists than by which steps they own and which steps they leave to application code.

3.1 Give the Run a Durable Identity

To keep the six responsibilities from becoming six unrelated vocabularies, the rest of this chapter follows one record: expense run E-1042. It is not the full chat transcript. It is the application ledger that answers where the task is, what may happen next, and where recovery begins. The model, tool runtime, approval UI, and ERP system see different projections, but all of them return to the same run identity.

{
  "expense_run_id": "E-1042",
  "applicant": "alice",
  "invoice_ref": "INV-77",
  "amount": null,
  "policy_result": null,
  "pending_action": null,
  "approval": "not_required_yet",
  "idempotency_key": "expense:E-1042:commit",
  "erp_receipt": null,
  "status": "submitted"
}

After the invoice read, the tool layer changes only amount to 12800. The policy check then records “manager approval required.” The permission gate does not write to ERP; it stores pending_action=write_expense and a resume key, then advances the record to waiting_approval. Approval creates a new invocation that still references E-1042 and the original idempotency key. Only the ERP receipt ERP-778 advances the task to completed.

This separates three kinds of visibility. The ledger may retain a full tool result, the next model call may receive only a projection, and the approval UI may expose only the amount, reason, and pending action. Persisted does not mean model-visible, and model-visible does not mean authorized.

This chapter puts AgentScope, Pi, Google ADK Python, Agno, AutoGen, CrewAI, Eino, and tRPC-Agent-Go on one map. It also keeps OpenAI Agents SDK nearby as a lightweight but important reference point. This is a reading coordinate system, not a benchmark.

This chapter answers five questions:

1. What is an agent framework beyond a model plus a few tools?
2. Which six responsibilities appear when an agent enters a real product?
3. Where do Pi, AgentScope, ADK, Agno, AutoGen, CrewAI, Eino, and tRPC-Agent-Go place their strongest abstractions?
4. Why are multi-agent labels and feature counts poor starting points?
5. In what order should the next twelve chapters be read?

Four terms recur across the series. Fixing their level now prevents a common collapse: a record can exist on disk without being visible to the model, and a framework can project a view without owning the durable source record.

4. Turn The Six Steps Into Runtime Owners

A minimal agent demo usually has three parts: instructions, a model client, and tool functions. That is enough for a sample, but not enough for a product runtime. The real problems appear after the first turn: what if a tool result is too large, a user rejects a command, the model emits several tool calls, the web UI needs typed progress events, a background job wakes a session, or a worker agent needs to report back to its leader?

That is why framework comparison should start by separating owners. An owner is not a directory name. It is the place where a responsibility gets its input/output shape, state update point, failure boundary, and application handoff.

The rest of the series can be read through one shape-level trace. This is not any framework's exact struct. It is the state movement to keep in view while reading source:

Expense run E-1042: "read INV-77 and submit the claim"
  -> model loop: create an invocation id and project necessary history
  -> tool runtime: turn read_invoice into a schema-validated tool call
  -> permission gate: decide read-only, confirmation required, or denied
  -> state ledger: record amount, tool_call_id, result, and pending_action
  -> workflow graph: route a complete but high-value claim to approval
  -> service plane: project an approval summary and persist a resume key
  -> application: write with expense:E-1042:commit and store ERP-778

Each chapter asks the same question against that trace: which object receives the input, which gate changes the path, which record lets the next turn continue? If an article can only name Agent, Tool, and Memory classes but cannot replay this movement, it has not really explained runtime ownership.

5. Put the Frameworks on One Map

The real difference is not whether a README says agent, workflow, or memory. It is which layer the project makes a first-class abstraction. Some start from workflow graphs, some from multi-agent conversation, some from a service control plane, and some fold tools, permissions, and workspace boundaries into a single agent runtime.

The OpenAI Agents SDK is another useful reference. Its core concepts include agents, tools, handoffs, guardrails, sessions, tracing, and realtime agents. It shows that lightweight does not mean ownerless; it means the owners are narrower and closer to the model/application boundary.

6. Do Not Start With Multi-Agent

Multi-agent demos are attractive because they are easy to name: planner, researcher, coder, reviewer. But if source reading starts with role names, coordination looks like prompt text. The more durable questions are below that layer: is a handoff a tool call, does the worker have an independent session, which memory is shared, do permissions inherit, how does the result return, and can failure be resumed?

AutoGen matters for exactly this reason. It pushed the community to treat multi-agent conversation, teams, handoffs, and agents as tools as serious abstractions. Its current README, however, says the project is in maintenance mode and recommends Microsoft Agent Framework for new users. This series will read AutoGen as abstraction history and migration context, not as the default starting point for new systems.

In E-1042, a safer decomposition lets every worker update the parent record rather than own the final side effect. Invoice extraction adds the amount, policy analysis adds the rule result, and approval communication adds an approve or reject decision. None of those workers may write ERP directly. Only the parent workflow, which owns the idempotency key and all prerequisites, can submit the claim. Multi-agent decomposition changes analytical ownership; it does not have to distribute side-effect authority.

Pi offers a different correction: not every familiar capability belongs in core. It stabilizes providers, the agent loop, tool batches, events, an append-only session tree, and compaction, while leaving plan mode, sub-agents, MCP, remote tools, and permission interaction to extensions. That boundary separates mechanisms the runtime must guarantee from policies a product may choose.

CrewAI, Eino, and tRPC-Agent-Go show three different corrections. CrewAI separates collaborative roles from business flows, so autonomous work and deterministic routing do not collapse into one prompt. Eino takes the Go route: define components and compose graphs first, then place agent patterns inside that composition model. tRPC-Agent-Go continues into a Go service runtime, where Runner, GraphAgent, tools, Skills, artifacts, the server plane, summary, durable memory, and hidden-history recall need separate owners.

7. Reading Route: Fix The Minimal Core, Then Expand The Runtime

Part 2 starts with Pi, not because Pi outranks the other frameworks, but because it draws a clear core boundary. Provider adapters, the agent loop, tool results, events, and sessions must remain stable; plans, sub-agents, MCP, and concrete permission policy can stay in extensions. Once readers know what cannot be removed, later chapters can show exactly which additional responsibilities each framework takes over.

These four stops form the foundation: Pi fixes core, AgentScope expands runtime, the worksite chapter separates deployment from state owners, and the protocol chapter places that runtime at system boundaries. Then ADK's workflow runtime, Agno's platform plane, AutoGen's migration into Microsoft Agent Framework, CrewAI's Crews/Flows, Eino's Go composition, and tRPC-Agent-Go's long-context ledgers can be read as different choices of owner rather than different API names.

8. Keep This Decision Table Nearby

8.1 Selection Still Needs an Adoption Gate

For the expense product, finding Session, Workflow, or Approval in a README establishes only a candidate capability. The team still needs four fixed acceptance cases: Alice and Bob never share records; a service restart while approval is pending can recover E-1042; repeated submission of the same idempotency key produces one ERP receipt; and the audit record can reconstruct who approved which action and when.

When a framework does not own one of these responsibilities, the application must own and test it explicitly, or the framework should be rejected for this product. Keep three states separate: the runtime produced an output, acceptance tests validated recovery and side effects, and the product authority adopted the implementation. A class name, demo, or single successful run cannot skip the last two states.

The next chapter enters Pi by following one “change the code and run the tests” task: how the model repeatedly proposes tool calls, how events report progress, how the original conversation remains in a JSONL tree, and why an overlong context is projected again rather than erased.

Sources

• AgentScope
• Pi
• Google ADK Python
• Agno
• AutoGen
• Microsoft Agent Framework
• CrewAI
• Eino
• tRPC-Agent-Go
• OpenAI Agents SDK