Part I — What survives, and where to go next
Part I teaches a production-agent architecture through one implementation and then builds it a second time. Before moving on, separate the two things the labs have shown you together: the properties the architecture depends on, and the way one toolkit happens to provide them.
What should survive an implementation change?
The agent runtime is the most replaceable box in the template. It has already been replaced once: the Rig and Rust implementation swaps NeMo Agent Toolkit for a thin Rust framework while the gateway, the MCP server, the database, the prompts and the evaluation suites stay the same. The same can happen in your system with a different framework, a managed agent platform or code you write yourself.
Whatever replaces it, these properties should still be true, and you should be able to point at the code or configuration that makes them true:
| Boundary | Property that must survive | How to check it on any runtime |
|---|---|---|
| Identity | The caller is established by the gateway, never by conversation text. | Send a request without the service key, or with two identity headers, and expect a refusal before any model call. |
| Capability | The tool list is a grant. The model reaches data only through tools, and the agent has no route to the database. | List the tools the runtime exposes and compare them with the allow-list. Inspect the network the agent runs on. |
| Execution responsibility | The model proposes a call; the runtime executes it, and the tool service decides whether a mutation is valid. | Find the code that refuses an unlisted tool or a malformed argument, and the server-side check that re-validates it. |
| Model and tool separation | No credential appears in a prompt, tool description, tool argument or tool result. | Read one full trace and search it for keys and tokens. |
| Authority (where enabled) | A state change needs a human approval verified at the point of mutation, not in the agent. | Replay an approval token, or change the premise it was signed for, and expect the MCP server to refuse it. |
| Evidence | Each request produces one correlated trace, without raw identity headers. | Run a request and find exactly one trace for it. |
| Measured behaviour | A change of runtime is judged by the same evaluation suites, not by impression. | Run make eval-all and compare results tagged with provenance.agent.runtime. |
Some things are allowed to differ, as long as the difference is documented. On the two implementations, PII masking is narrower on Rig, the tool-argument policy is stricter, the execution state is explicit rather than hidden, and the container images differ by more than an order of magnitude in size. NAT vs Rig lists every deliberate difference. Any difference not on that list should be treated as an unexplained divergence, to be investigated until it is documented or corrected.
The test of understanding is simple: can you still recognise the architecture after the framework has been replaced? If the answer depends on the framework's vocabulary, go back to the invariants before continuing.
Continue beyond this laboratory
You now understand this architectural problem. These are strong implementations, standards or ecosystems to explore next. They are a short, deliberate selection; Where CognoKratos fits explains how they were chosen and what the labels mean.
- NVIDIA NeMo Agent Toolkit portable open source
The toolkit under the canonical implementation. Read its documentation to see which of the properties above it provides and which the template adds around it. - OpenAI Agents SDK portable open source
A deliberately small framework with tools, guardrails, human-in-the-loop and tracing. Try mapping its primitives onto the template's boundaries, and note which features rely on the OpenAI platform. - Strands Agents portable open source
An open-source SDK from AWS that runs in your own process with many model providers. A third way to realise the same agent box, between NAT's breadth and Rig's minimalism. - Rig portable open source
The Rust library behind the comparative implementation. Its documentation shows how little an agent framework needs to provide, and therefore how much your own code must.
If the agent loop or tool calling still felt unfamiliar in this part, revisit the learning paths before continuing.