AI Agent Platforms: Agent Frameworks to Full-Stack Platforms

TL;DR

• "Agent framework" is used for several different kinds of tool: agent SDKs, orchestration runtimes, workflow platforms, tool protocols, memory infrastructure and full agent platforms.
• An agent framework gives you building blocks; an agent platform provides the runtime, state, memory, security, governance, observability and optimisation needed to operate agents in production.
• OpenAI Agents SDK, LangChain, LangGraph, CrewAI, AutoGen and n8n each cover part of the production stack. MCP is a connectivity layer, not a platform.
• Minns is a full-stack agent platform: ten layers from isolated microVM compute up to the agents themselves, built around temporal memory (MinnsDB), which lets agents reason about what was true at a given point in time rather than treating all stored facts as current.
• Production agents also need an optimisation loop: capture execution traces with OpenTelemetry, score runs with judges, and improve behaviour with Automatic Prompt Optimisation (APO). The Minns Optimiser runs that loop in the platform: content-rich traces, an independent judge, prompt evolution replayed against recorded tool calls, and an apply gate that only ships a change when it beats the noise.

---

Building an AI agent is becoming relatively easy.

Building one that can run reliably for weeks, maintain state, use real business systems, recover from failures, respect permissions, remember what happened, improve over time and be operated in production is considerably harder.

That gap creates a problem in today's tooling landscape. SDKs, orchestration frameworks, workflow builders, memory systems and complete agent platforms all get grouped under the same label: agent frameworks.

They are not the same thing.

So the useful question in 2026 isn't "Which agent framework should I use?" It's:

How much of the agent stack do I want to build and operate myself?

The agent stack is getting bigger

An early AI agent could be surprisingly simple:

User → LLM → Tool → LLM → Response

That's enough for a prototype. A production agent looks more like this:

                 ┌──────────────────┐
                 │   Agent Builder  │
                 └────────┬─────────┘
                          ↓
┌─────────────────────────────────────────────────┐
│                  Agent Runtime                  │
│    Planning · Tools · Handoffs · State · Loops  │
└───────────────────────┬─────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────┐
│                      State                      │
│   Memory · Temporal State · Context · History   │
└───────────────────────┬─────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────┐
│                   Operations                    │
│ Security · Governance · Observability · Evals   │
│                  Optimisation                   │
└───────────────────────┬─────────────────────────┘
                        ↓
              External systems / tools

The model is only one component. Choosing an agent framework increasingly means choosing an architecture.

Agent framework vs agent platform: what's the difference?

An agent framework provides abstractions for building agents, such as tools, loops and handoffs. An agent platform provides the infrastructure to run and operate agents in production, including durable execution, memory, security, governance, observability, evaluation and optimisation.

More precisely, the tools in this space fall into several categories:

• An agent SDK gives you primitives for building an agent.
• An agent framework gives you abstractions for constructing agent applications.
• An orchestration runtime manages execution, state and workflow control.
• A workflow platform connects applications, triggers and business logic.
• A tool protocol standardises how agents talk to external tools.
• An agent platform brings several of these together.

These are complementary categories, not direct substitutes.

Category	Primary job	Examples
Model API	Generate responses and tool calls	OpenAI, Anthropic, Google
Agent SDK	Agent loops, tools, handoffs	OpenAI Agents SDK
Agent framework	Agent abstractions and integrations	LangChain, CrewAI, AutoGen
Orchestration runtime	State, branching, durable execution	LangGraph
Workflow platform	Visual business automation	n8n
Tool protocol	Connect agents to tools and data	MCP
Memory infrastructure	Persistent agent context	Mem0, Zep, databases
Agent platform	Build, run, operate and optimise agents	Minns

The catch is that a production application usually needs several rows from this table.

Three ways to build an agent platform

1. Assemble the infrastructure yourself

OpenAI Agents SDK
  + Postgres
  + Vector database
  + LangGraph
  + MCP
  + Observability
  + Authentication
  + Evaluation
  + Optimisation
  + Deployment infrastructure

Maximum control. It also means your engineering team owns the integration between every component.

2. Compose around an agent framework

LangChain + LangGraph + LangSmith + your own infrastructure

This removes a lot of implementation work while keeping architectural flexibility. For many teams it's a perfectly reasonable choice. But the system is still a collection of components you hold together.

3. Use a full-stack agent platform

A platform provides most of the infrastructure as one system. This is the approach Minns takes.

What does a production agent actually need?

Ignore the branding and look at the requirements:

• Compute and isolation: somewhere safe for the agent, its tools and its code to run, separated from everything else.
• Agent construction: defining agents, instructions, tools and behaviour.
• Runtime: reliable execution of model calls, tools, loops and handoffs.
• Durable state: pause, resume and recover without losing progress.
• Memory: information that survives individual conversations or runs.
• Temporal state: understanding that information changes over time.
• Context: selecting what's relevant to the current task.
• Integrations: connections to business apps, APIs and tools.
• Security: authentication, authorisation and controlled tool access.
• Governance: policies on what agents are allowed to do.
• Observability: seeing what an agent saw, decided and did, ideally as standard OpenTelemetry traces.
• Evaluation: measuring whether prompt, model or tool changes actually help.
• Optimisation: systematically improving behaviour based on real execution.
• Deployment: environments, promotion, rollback and a way to reach the agent (API, chat, schedules, other agents).
• Compliance: evidence that the controls above exist, for auditors and regulators (the EU AI Act now asks for it).

Most frameworks solve some of these. Very few try to solve all of them in one environment.

Where the major frameworks fit

OpenAI Agents SDK

A lightweight, code-first SDK with primitives for agent loops, tools, guardrails, handoffs, sessions, human-in-the-loop, MCP and tracing.

It's a good fit when you want a small set of primitives and are happy to own the wider architecture. It's an agent SDK, not a complete infrastructure platform.

LangChain

A higher-level abstraction layer with a broad integration ecosystem. Its value is reducing the plumbing between models, tools and application components, and for many applications that's exactly what's needed.

As applications become more stateful, teams typically add LangGraph and other infrastructure. That can be powerful, but you're composing the platform from parts.

LangGraph

LangGraph is an orchestration runtime. It focuses on execution and state: long-running execution, branching, checkpoints, human intervention, retries, persistence and resumability. It also offers a store for long-term memory.

That makes it one of the most relevant tools for serious agent applications. Its core job is orchestration, though, so you still decide how temporal state, auth, governance, deployment and optimisation fit around it.

CrewAI

CrewAI's abstractions are agents, roles, tasks, crews and flows, with built-in memory options. It's attractive when a problem naturally maps onto multiple specialised agents.

The trade-off is complexity. Every extra agent adds another context, handoff and failure path to evaluate. Multi-agent systems aren't automatically better than single-agent ones.

AutoGen

AutoGen offers abstractions around agents, teams, messages and termination conditions, and suits designs where agent collaboration is central. (Microsoft has since folded much of this work into its newer Agent Framework, so check which you're evaluating.)

Again, a team abstraction is only one part of operating a production system. State, security, evaluation and operations still need to live somewhere.

n8n

n8n is fundamentally a workflow automation platform. Its strength is flows like:

Trigger → Business system → AI step → Business logic → Human approval → Another system

That's extremely useful when the agent is one component of a wider business process. It's less natural when the core problem is a complex, long-running agent with its own state, memory and execution model.

MCP is not an agent platform

MCP (Model Context Protocol) is a standard for connecting AI applications to external tools and data. It has become a key part of the ecosystem, but it solves a different problem from agent frameworks and platforms.

MCP does not determine:

• what an agent should do
• how it remembers previous events
• how execution resumes after failure
• whether an action needs human approval
• how the agent is evaluated or improved
• how permissions work
• how production runs are observed

It's a connectivity layer. A platform can use MCP without being replaced by it.

The full-stack approach: Minns

Minns is a full-stack platform for building, running, governing and optimising production AI agents. The idea is simple: an agent shouldn't have to assemble its own infrastructure before it can become a production system.

We describe it as ten layers, from the machines up to your agents. Each one is something that runs today, not a roadmap item.

10  Your agents         managed, from your repo, or external · Slack, API, A2A, schedules
 9  Build               copilot · canvas + graph IR · blueprints · GitOps deploy
 8  Observe + optimise  content-rich traces · independent judge · prompt evolution · gated apply
 7  Governance          policies with honest modes · approvals · audit log · budgets · EU AI Act dossier
 6  Security            guardian on every model call · PII masking · flow labels · egress allow-list
 5  Agent runtime       adaptive runner · checkpointed graph engine · reasoning engines · key-holding proxy
 4  Integrations + MCP  connected apps · custom tools as MCP · external MCP servers · A2A
 3  Context             ~50 connectors + document reader in · hybrid, evidence-backed recall out
 2  Temporal memory     MinnsDB: bi-temporal graph + bi-temporal tables, one query language
 1  Compute + durability isolated microVMs · dedicated or pooled MinnsDB · runs that survive restarts

Going up the stack:

1. Compute and durability. Every agent and every custom tool runs in its own isolated microVM. Coding agents get a sandboxed workspace where the files the model edits are the files its commands run against. Runs and schedules are durable, so they survive restarts, and you choose EU or US hosting.
2. Temporal memory. MinnsDB, covered in more detail below.
3. Context. Around 50 connectors (Slack, Jira, GitHub, Salesforce, Gmail and more) plus a document reader that turns PDFs and pages into a section tree with evidence. Recall is hybrid search, ranked, and returns the claims behind each answer.
4. Integrations and the MCP hub. You connect an app once and allow it per agent. Custom tools are built, tested and served as MCP from their own microVMs behind one gateway. Agents can also use external MCP servers, and talk to other agents over A2A.
5. Agent runtime. An open SDK with an adaptive runner that picks a tool loop or a graph pipeline per task, a graph engine with checkpoints and interrupts, reasoning engines (tree search, self-critique, world model), middleware, sub-agents and a code mode. Model calls go through a proxy that holds the provider keys, so keys never enter the workload.
6. Security. A guardian checks every model call for injection, jailbreaks and moderation issues. Personal data (names, IBANs, card numbers) is pseudonymised before the model sees it and restored afterwards. Information-flow labels, an egress allow-list, sealed secrets, role-based access and scoped API tokens complete the layer.
7. Governance. Policies run in enforce, monitor or off mode, and a policy that's only planned is never counted as a control. Gated actions pause for a person behind a signed one-time link: the tool proposes, a human approves, then the original call runs. Everything goes into an append-only audit log, alongside budgets and dev/staging/prod environments with rollback. The EU AI Act dossier is filled in from these controls as evidence.
8. Observability and the optimiser. Every model and tool call is traced as OpenTelemetry spans with its content, and logs are shipped too. An independent judge scores the runs, and the optimiser evolves prompts against them (more on this below).
9. Build. A copilot turns a sentence into a deployed agent. A canvas compiles every node to something that runs. There are blueprints, a service builder with a test loop, and GitOps deploys when you push a repo with a manifest.
10. Your agents. Managed agents, agents built from your own repo, or agents registered from elsewhere. One agent or a team of routers, workers and sub-agents. Reached over Slack, the public API, A2A and schedules.

What is temporal memory for AI agents?

Temporal memory stores how information changes over time, so an agent can distinguish current state from historical state.

Traditional RAG is optimised for: "What information is relevant to this query?"

A long-running agent often needs: "What was true at this point in time?"

Take a customer relationship:

Today:          Customer is considering renewal.
+3 weeks:       Customer has renewed.
+6 months:      Customer has expanded their contract.

A useful agent shouldn't retrieve all three facts and treat them as simultaneously current. It needs to understand how the state evolved.

MinnsDB is the temporal memory database at the core of Minns. It is bi-temporal, so it tracks two timelines: when a fact was true in the world, and when the agent learned it.

• The graph holds what the agent believes. Every fact carries a validity window. New facts supersede old ones rather than deleting them, and an ontology says how they interact: which properties are single-valued, which are symmetric, which are append-only, and which facts cascade when something they depend on changes. The ontology can also propose new rules from patterns in the data, for a person to approve.
• Tables hold what the agent is told. Records such as orders, contracts and tickets live in bi-temporal tables, versioned the same way and joined to the graph.
• One query language asks both questions. MinnsQL can ask what was true at a time (WHEN) and what the agent believed at a time (AS OF), across graph and tables in one query. There's also a natural-language query endpoint and live subscriptions that push changes as they happen.

Beyond facts, MinnsDB keeps structured memory (ledgers with balances, state machines, preferences), episodes and learned strategies. Outcome feedback updates the value of the memories and strategies an agent actually used, so retrieval favours what has worked before.

This matters most for agents that run continuously rather than for a single conversation.

Agent optimisation: closing the loop with OpenTelemetry and APO

Most agents are improved the same way: someone reads a few bad transcripts, edits the prompt, tries a handful of examples and ships it. That works for a prototype. It doesn't scale to agents running thousands of tasks a week, where a prompt change can fix one workflow and quietly break three others.

Agent optimisation is the process of systematically improving an agent's behaviour using evidence from its real executions. It needs three things: good data about what the agent did, a reliable signal for whether it did well, and a safe way to change it.

The optimisation loop

        ┌──────────────┐
        │  Agent runs  │
        └──────┬───────┘
               ↓
   Trace (OpenTelemetry spans)
               ↓
   Judge (LLM judges, rules, human feedback, outcomes)
               ↓
   Attribute (which run and prompt caused the outcome?)
               ↓
   Optimise (APO proposes prompt changes)
               ↓
   Validate (replay against evals, compare)
               ↓
   Deploy (versioned, with approval)
               ↓
        back to Agent runs

Each stage depends on the one before it. You can't judge what you didn't record, and you can't safely deploy a change you didn't validate.

Step 1: Capture traces with OpenTelemetry

OpenTelemetry (OTel) is the open, vendor-neutral standard for traces, metrics and logs, and it now has semantic conventions for generative AI. These define a common shape for agent telemetry: spans for model calls, tool executions and agent invocations, with attributes for the model used, token counts, and inputs and outputs.

A single agent run becomes a tree of spans:

invoke_agent  support-triage
├── chat          (model call: classify the ticket)
├── execute_tool  crm.lookup_customer
├── chat          (model call: draft the reply)
└── execute_tool  helpdesk.update_ticket

Using OTel rather than a proprietary trace format matters for optimisation because:

• It's framework-neutral. Traces from different SDKs, frameworks and services share one format, so you can optimise across a mixed stack.
• It connects agent behaviour to the rest of the system. The same trace can include the database query, the API call and the downstream service, so you can see whether a failure came from the prompt or the infrastructure.
• It avoids lock-in. Your execution history stays usable if you change observability or optimisation tooling.

The GenAI conventions are still evolving, so expect attribute names to shift, but the direction is clear: agent telemetry is becoming standard telemetry.

Step 2: Judge the runs

Traces tell you what happened, not whether it was good. Judging turns runs into signal, usually by combining:

• Deterministic checks: did the output match the schema, did the tool call succeed, was a policy violated?
• LLM judges: a model scores the run against a rubric (was the answer correct, grounded, on-policy?).
• Human feedback: approvals, corrections and escalations from people in the loop.
• Business outcomes: did the ticket stay closed, did the customer renew, did the invoice get paid?

The last category is the most valuable and the hardest to get, because business outcomes often arrive days or weeks after the run that caused them.

Judges also need judging. An LLM judge that's too lenient, inconsistent or biased towards long answers will steer any optimiser in the wrong direction, so judges should be calibrated against human-labelled examples and monitored like any other component.

Step 3: Automatic Prompt Optimisation (APO)

Automatic Prompt Optimisation (APO) uses a model to improve prompts based on evidence from failures. Rather than a human editing prompts by intuition, an APO process typically:

1. Collects runs the judges scored badly.
2. Asks a model to critique what went wrong, producing a natural-language "gradient" (for example, "the prompt doesn't say what to do when the customer record is missing").
3. Generates candidate prompt edits that address the critique.
4. Scores each candidate against an evaluation set.
5. Keeps the best candidates and repeats (a beam search over prompts).

The approach comes from research on "textual gradient" prompt optimisation and now appears in open-source tooling such as Microsoft's Agent Lightning, alongside related optimisers in frameworks like DSPy.

APO is powerful, but it has sharp edges:

• It optimises for whatever you measure. A weak or biased judge produces prompts that please the judge, not users.
• It can overfit. A prompt tuned on 50 failures can regress on the 5,000 cases that were working.
• It needs versioning and rollback. Every optimised prompt is a deployment and should be treated like one.

This is why APO belongs inside a loop with judging, validation and approval, not as a script someone runs occasionally.

Why memory matters for optimisation

Most optimisation setups treat each trace as an isolated example. That misses the most useful signal.

Go back to the customer example. An agent handles a renewal conversation today. Whether that conversation went well may only be clear three weeks later, when the customer renews or churns. To learn from it, the optimiser has to connect that later outcome back to the specific run, prompt version and decisions that preceded it.

That's a temporal problem: which prompt version was live, what did the agent know at that moment, and what happened afterwards? Without persistent, time-aware state, outcome attribution collapses into guesswork, and optimisation falls back to judging runs in isolation.

How Minns approaches optimisation

Minns treats optimisation as part of the platform rather than a separate tool. The loop above runs inside it:

• Traces with content. Agents export OpenTelemetry GenAI spans with the messages, tool arguments, results and failures on them. Each span is tagged with a run id, so every trajectory can be reassembled, and runs are clustered into workflows.
• An independent judge. A judge model, separate from the model being optimised, scores each run against the workflow's rubric. It sees the tool calls as well as the final answer. Different kinds of evidence carry different weight: a human correction counts for more than a judge score, and a judge score counts for more than an implicit signal.
• Prompt evolution, not blind rewriting. The optimiser keeps a pool of prompt variants and prefers the variant that wins on the most individual cases, not the one with the best average. A stronger model reads that variant's worst cases, diagnoses what went wrong and writes an improved prompt. It can also merge two variants that are strong on different cases. Geometric guidance keeps the search honest: candidates are embedded, near-duplicates are rejected, and if the pool starts to collapse into one idea the rewriter is pushed to take a different angle. Operators' rejection notes feed into the next run, and the optimiser doesn't run at all if the agent is already good enough.
• Replay against recorded tool calls. Candidate prompts are tested on real inputs, worst-scoring first, with the agent's real tool schemas. When a candidate calls a tool, it gets back what that tool actually returned in production. A slice of inputs is held out, and the winner has to beat the baseline there on repeated scoring, with the noise reported.
• A gated apply. A winning prompt becomes a versioned suggestion. It's applied only if it clears the noise floor and a golden set of test cases, and it can be rolled back. Deployed agents fetch their current prompt from the platform, so applying a change doesn't need a redeploy.
• Memory underneath. Because traces, judgements and MinnsDB sit in one system, the pieces for outcome attribution are already there: runs are tagged with the prompt version that produced them, and memory is bi-temporal. Connecting business outcomes that arrive weeks later back to those runs automatically is the next step we're building, and it's the part of the loop a standalone optimiser can't do.

The difference from a standalone optimiser is where the evidence comes from: real traffic, real tool results and a platform that already knows which version was live.

Comparing the approaches

This compares architectural scope, not model quality or popularity. "Your app" means the capability is possible but you build or integrate it yourself.

Capability	OpenAI Agents SDK	LangGraph	CrewAI	n8n	MCP	Minns
Isolated compute / sandboxes	Your app	Your app	Your app	Partial	n/a	✓ (microVMs)
Agent building	✓	✓	✓	✓	n/a	✓
Agent runtime	✓	✓	✓	✓	n/a	✓
Durable execution	Partial	✓	Partial	✓	n/a	✓
Persistent memory	Partial (sessions)	✓ (store)	✓	Partial	n/a	✓
Temporal state	Your app	Your app	Your app	Your app	n/a	✓
Context layer	Partial	Partial	Partial	Partial	Partial	✓
Tool integrations	✓	✓	✓	✓ (extensive)	✓	✓
Security	Partial	Your app	Partial	Partial	Partial	✓
Governance	Partial	Your app	Partial	Partial	n/a	✓
Observability	✓	Via LangSmith	✓	✓	n/a	✓
Evaluation	Partial	Via LangSmith	External	Partial	n/a	✓
Optimisation	Your app	Your app	Your app	Limited	n/a	✓ (judge, prompt evolution, replay)
Deployment and environments	Your app	Via LangSmith	Partial	✓	n/a	✓
Compliance evidence	Your app	Your app	Your app	Your app	n/a	✓ (EU AI Act dossier)
Full-stack platform	No	No	No	No	No	Yes

Based on public documentation as of September 2026. These products move fast; if something's out of date, tell me and I'll fix it.

The point isn't that the others can't be combined to reach the same result. They can. The difference is where the integration work lives: with a framework stack you assemble the platform; with a full-stack platform, the platform does.

Assemble or consolidate?

This is an architectural decision, not a question of which tool is "best". Both paths are legitimate, and the right answer depends on your team and on what the agent is for.

Assembling your own stack makes sense when:

• You have platform engineers who want control over every layer, and the time to maintain the integrations.
• You already run strong infrastructure for observability, auth and deployment, and agents are one more workload on top of it.
• Your agents are short-lived or stateless, so memory and temporal state barely matter.
• You need a specific component (a particular vector store, orchestration engine or model host) for regulatory or contractual reasons.

Consolidating on a platform makes sense when:

• Your agents run continuously and have to track state that changes: customers, deals, tickets, projects.
• You want the optimisation loop (traces, judges, APO, validation, deployment) running from the start, not bolted on after the first production incident.
• Governance and approval are requirements, not nice-to-haves.
• Your team would rather spend its time on agent behaviour than on the plumbing between ten components.

A useful test is to list the requirements from earlier and write down, for each one, who owns it in your proposed architecture. If the answer is "us" for most of them, you're building a platform, whether or not you meant to. That can be the right call. It's just worth making deliberately.

The two paths also aren't mutually exclusive. Because the interfaces are increasingly standard (MCP for tools, OpenTelemetry for traces), you can start with a framework and add platform capabilities later, or run framework-built agents on a platform and keep the code you already have.

Frequently asked questions

What is the difference between an agent framework and an agent platform?

An agent framework provides abstractions for building agents: tools, loops, handoffs and prompts. An agent platform provides the infrastructure to run and operate them in production: durable execution, memory, security, governance, observability, evaluation and optimisation.

Is LangGraph an agent platform?

LangGraph is an orchestration runtime. It handles durable, stateful execution very well and offers a long-term memory store, and LangSmith adds observability and evaluation. Temporal state, governance and optimisation are still yours to build or integrate.

Is MCP an agent framework?

No. MCP is a protocol for connecting AI applications to tools and data. It standardises connectivity, not agent behaviour, memory, execution or governance.

What is temporal memory?

Temporal memory records how facts change over time, so an agent can tell current state from historical state and answer questions like "what was true on this date?" rather than retrieving every fact as if it were still current.

What is Automatic Prompt Optimisation (APO)?

APO uses a model to critique failed runs, propose prompt edits that address the critique, and score those edits against an evaluation set, repeating the process to search for better prompts. It works best inside a loop with calibrated judges, validation and versioned deployment.

Why use OpenTelemetry for agent traces?

OpenTelemetry is the vendor-neutral standard for traces, metrics and logs, and its generative AI semantic conventions give agent telemetry a common shape. That makes traces portable across frameworks and tools, and lets you see agent behaviour alongside the rest of your system.

Conclusion

The agent framework market is really several markets: SDKs, orchestration runtimes, workflow tools, protocols, memory systems and platforms. Comparing them head-to-head is like comparing a web framework with a cloud provider. Both are useful. They answer different questions.

As agents move from demos to systems that run for months, the hard problems shift away from calling a model and towards everything around it: state that changes, actions that need approval, runs that need explaining, and behaviour that needs to get better over time without breaking what already works.

So before choosing a tool, decide how much of that stack you want to own. If the answer is "most of it", pick the SDK or framework that fits your team and budget for the integration work. If the answer is "as little as possible", a full-stack platform is worth a serious look.

That's the bet we're making with Minns: ten layers in one system, from isolated compute and temporal memory up through runtime, security, governance and optimisation, so the agent you build on day one is the one you can still operate, explain and improve on day three hundred.

If you're building production agents and want to compare notes, or think I've got something wrong about any of these tools, leave a comment or find me at minns.ai.