Where CognoKratos fits

Learn the architecture. Then choose the implementation.

Engineers who build agents today choose from an ecosystem that is large and moving fast. There are courses that teach the fundamentals. There are frameworks and managed platforms that run agents, durable runtimes that keep them alive, policy engines and governance toolkits that constrain them, protocols that connect them, and wallets and payment rails that let them touch value. Much of it is excellent work, by vendors and by open communities.

CognoKratos does not try to replace any of it. This chapter shows where the book sits in that ecosystem, how it labels the projects it mentions, and how to read those projects through the trust boundaries the book uses.

Between the fundamentals and the implementation

flowchart TB
    F["Learn the fundamentals<br/>Hugging Face · Microsoft · AWS · Anthropic · OpenAI"]
    C["CognoKratos<br/>the architecture and trust boundaries<br/>between the components"]
    F --> C
    C --> FW["Frameworks and runtimes<br/>NeMo Agent Toolkit · Strands<br/>OpenAI Agents SDK · Dapr Agents · Rig"]
    C --> GV["Governance and policy<br/>Agent Governance Toolkit · AgentCore Policy<br/>ACS · OPA · Cedar · OpenFGA"]
    C --> IN["Identity, value and settlement<br/>ERC-8004 · AgentKit · x402<br/>Nevermined · Olas · uAgents"]
    FW --> S["Your system"]
    GV --> S
    IN --> S

These projects are not alternatives to CognoKratos. They solve problems the book deliberately does not attempt to own. CognoKratos focuses on the architectural boundaries between them: what each one guarantees, what it leaves to you, and what must still be true when they are composed into a system whose actions matter.

CognoKratos is not the box at the bottom. It teaches you how to choose and compose the boxes.

How the book labels external projects

The book gives each external project one of three labels. They answer a single engineering question: how tightly is this project coupled to a particular vendor or platform? They say nothing about quality, and they are a reader aid, not a legal or governance taxonomy.

Ecosystem-specific ecosystem-specific
Materially tied to one vendor's managed platform, hosted service, API or product ecosystem. Examples: Amazon Bedrock AgentCore and AgentCore Policy, the Nevermined platform. This is often the right engineering choice when the surrounding ecosystem already fits your system.

Portable open source portable open source
Open-source software you can run yourself, usable across providers or environments, even when one company leads its development. Examples: NVIDIA NeMo Agent Toolkit, Microsoft Agent Governance Toolkit, Strands Agents, the OpenAI Agents SDK, Rig, Dapr Agents, Temporal. The label describes portability of the implementation, not neutrality of its governance.

Open standard / infrastructure open standard / infrastructure
Open standards, specifications, protocols and foundation- or community-governed infrastructure intended to work across vendors and stacks. Governance and maturity differ, and some are drafts or pre-1.0. The label covers two kinds of thing: protocols and specifications such as MCP, A2A, OpenID Connect, SPIFFE, ERC-8004, x402, AP2, the OWASP Agent Control Standard and Agent Hooks; and open infrastructure components such as OPA, Cedar, OpenFGA and the OpenTelemetry conventions, which you run or adopt rather than implement.

The labels need nuance, and the book tries to give it where it matters:

• Company-led does not mean locked in. NeMo Agent Toolkit does not need NVIDIA hardware and works with other frameworks and model providers. Strands runs outside AWS with many model providers, although Amazon Bedrock is its default. Microsoft's Agent Governance Toolkit has adapters for many agent frameworks and does not require Azure.
• Portable does not mean provider-neutral in every feature. The OpenAI Agents SDK can drive other models, but its hosted tools need OpenAI's Responses API, and by default its traces are exported to OpenAI. Those features are ecosystem-specific even though the SDK is not.
• Open standard / infrastructure does not mean identical governance. OPA, OpenFGA and Cedar are CNCF projects at different maturity levels, and Cedar originated at AWS. MCP and A2A are Linux Foundation projects. x402 has its own foundation, AP2 was contributed to the FIDO Alliance, and ERC-8004 follows the Ethereum improvement-proposal process.
• Open does not mean mature. Several specifications cited here are drafts, previews or pre-1.0 versions, and the book says so.

Learning resources are not labelled this way. They are described by the ecosystem they teach through: see If you are new to agents.

The ecosystem by trust boundary

The table maps the book's eight boundaries to examples of external work that addresses them. The examples are illustrations, not canonical implementations, and none of them settles a boundary by itself.

Two cautions apply to every row. First, a product that touches a boundary rarely closes it: a policy engine evaluates the rules you write, and an audit store keeps what you send it. Second, adopting infrastructure adds trust: the service that holds keys, evaluates policy or records evidence becomes part of the system you must reason about.

A short guide to the ecosystem

What follows is orientation, not a market survey. Each part of the book ends with a few resources chosen for that part's problem; this section shows how they fit together. Descriptions reflect upstream documentation in October 2026.

Learning the fundamentals

See If you are new to agents: the Hugging Face Agents Course as the broad, multi-framework path, and Microsoft-, AWS-, Anthropic- and OpenAI-focused paths for readers in those ecosystems.

Agent frameworks

• NVIDIA NeMo Agent Toolkit portable open source
  Adds configuration, MCP, observability, evaluation and optimisation to agents built with many frameworks. Part I's canonical implementation runs on it.
• Strands Agents portable open source
  An open-source SDK from AWS for Python and TypeScript that runs in your process, with Amazon Bedrock as its default model provider among many.
• OpenAI Agents SDK portable open source
  A small framework for agents, handoffs, guardrails, human-in-the-loop and tracing, usable with other model providers.
• Rig portable open source
  A Rust library for LLM applications with many model providers behind one interface. Part I's comparative implementation uses it. It is pre-1.0, and its README warns of breaking changes.
• Amazon Bedrock AgentCore ecosystem-specific
  AWS's managed platform for running and operating agents built with any framework and model, with services such as runtime, gateway, identity, memory, observability and policy. A production platform rather than a place to learn the fundamentals.

Durable runtimes

• Dapr Agents portable open source
  A Python agent framework from the CNCF Dapr project whose durable agents run on Dapr Workflows.
• Temporal portable open source
  A durable execution platform that replays workflows from their event history, with documented integrations for agent frameworks.

Both document that activities may run more than once and should be idempotent: durable execution makes a workflow resumable, not side effects exactly-once. Part II teaches why.

Governance and policy

• Microsoft Agent Governance Toolkit portable open source
  Policy enforcement, identity, sandboxing and audit around agent actions, with adapters for many frameworks. In public preview.
• Agent Control Standard open standard / infrastructure
  An OWASP GenAI Security Project specification for letting a separate guardian permit, deny or modify an agent's actions before they happen. Early (v0.1). Related early work includes Agent Hooks, a framework-neutral contract (version 0.1) for interception points in an agent's lifecycle, maintained as an open specification on GitHub.
• Open Policy Agent, Cedar and OpenFGA open standard / infrastructure
  General-purpose policy and authorisation engines, all CNCF projects: OPA (graduated) with the Rego language, Cedar (sandbox, originated at AWS) with analysable policies, OpenFGA (incubating) with relationship-based access control inspired by Google Zanzibar.
• AgentCore Policy ecosystem-specific
  A managed AWS service that evaluates Cedar policies on agent tool calls that pass through an AgentCore Gateway, and logs each decision. Compare it with the Agent Governance Toolkit: the same policy boundary, implemented once as portable open source you run, once as managed infrastructure you configure.

Identity and authorisation

• OpenID Connect open standard / infrastructure
  The identity layer Part I's gateway uses for human users.
• SPIFFE open standard / infrastructure
  A CNCF standard for identifying workloads, relevant when services and agents, not only people, need verifiable identities.

Cryptographic and wallet infrastructure

• Coinbase AgentKit portable open source
  A toolkit that gives agents wallets and on-chain actions through pluggable wallet providers, from Coinbase-managed wallets to keys you hold yourself.
• ERC-8004: Trustless Agents open standard / infrastructure
  A draft Ethereum standard for identity, reputation and validation registries for agents. It leaves payments explicitly out of scope.

Economic and payment infrastructure

• x402 open standard / infrastructure
  An open protocol for payments over HTTP, built on the 402 Payment Required status code, now stewarded by the x402 Foundation under the Linux Foundation.
• Agent Payments Protocol (AP2) open standard / infrastructure
  A pre-1.0 protocol in which signed mandates carry a user's authorisation of an agent's purchase. Originated at Google and contributed to the FIDO Alliance.
• Nevermined ecosystem-specific
  A platform for metering, access control and payments between agents, with open-source SDKs.
• Olas and Fetch.ai uAgents ecosystem-specific
  Open-source frameworks for autonomous agents that register, coordinate and transact on their own networks: the Olas protocol and the Fetch.ai Almanac.

Open standards and protocols

• Model Context Protocol open standard / infrastructure
  The tool protocol used across Parts I–V, now a project of the Linux Foundation's Agentic AI Foundation. Remember from Technology choices that MCP is a protocol, not a security model.
• Agent2Agent (A2A) open standard / infrastructure
  A protocol for communication between agents, also a Linux Foundation project.
• OpenTelemetry GenAI semantic conventions open standard / infrastructure
  Shared names for model, agent and tool spans; still in development.

The implementation spectrum

Every boundary can be implemented at different distances from your own code:

flowchart TB
    A["Managed platform<br/>e.g. Amazon Bedrock AgentCore, Microsoft Foundry"]
    B["Portable open-source framework<br/>e.g. NeMo Agent Toolkit, Agent Governance Toolkit, Strands, OpenAI Agents SDK"]
    C["Open standards and components<br/>e.g. MCP, Cedar, OPA, OpenFGA"]
    D["Minimal or custom implementation<br/>e.g. Rust on Rig, application-owned controls"]
    T(["more convenience"]) --- A --- B --- C --- D --- O(["more ownership"])

Towards the top, more implementation and operational responsibility is delegated to the provider. Some controls become properties of the managed service and its configuration rather than of your own code. That moves trust boundaries; it does not remove your side of a shared responsibility. You still configure, integrate and verify the service, and a well-run managed control does not by itself make the whole system correct. Towards the bottom you own more: every property is visible and testable in your code, and every property is also your responsibility.

The lesson is not that the bottom is better. The right position depends on a team's risk model, operational constraints, compliance needs, portability requirements, expertise, economics and trust boundaries, and it can differ from one boundary to the next in the same system. A team might run agents on a managed platform, express policy in open Cedar, and keep its approval check in its own database transaction.

What CognoKratos asks is that the choice be made knowingly. For each boundary, you should be able to say which guarantee you have delegated, to whom, and how you would notice if it stopped holding.

Recognising the architecture after a change

The implementation may change. The engineering property should survive.

The book's first demonstration of this is Part I. The same production agent is built twice: on NeMo Agent Toolkit, a mature framework that provides most behaviour through configuration, and in Rust on Rig, which leaves most of it to ordinary code. Everything except the agent stays the same, and the comparison shows which properties belong to the architecture rather than to the framework.

Each part ends with a chapter asking the same question of its own project: what should survive an implementation change?

Why CognoKratos focuses on understanding

Frameworks, platforms and protocols will keep changing; several projects in this chapter did not exist two years before this edition. The questions they answer change much more slowly: who is acting, what they can reach, what is permitted, what survives failure, who makes an action binding, what can be proven, who holds the keys, and how value becomes final.

A curriculum that owned an implementation of every layer would spend its effort competing with projects that do each layer better. CognoKratos keeps its reference implementations small and readable instead, so that the boundaries are visible, and points to the ecosystem for the rest.

About the external references

CognoKratos references external projects because good engineering starts by understanding and reusing existing work. Inclusion is not an endorsement, a dependency or a requirement. A resource is included because it illustrates an implementation, a standard or an alternative relevant to the architectural problem being studied, and each part keeps its list short on purpose.

External projects evolve independently of this book. Descriptions here were checked against upstream documentation for this edition, but names, licences, maturity and features change: consult each project's current documentation before relying on it. The book teaches principles; it does not promise compatibility with every project it cites. If a description has become wrong, please report it.