# AI Agent Platforms: Agent Frameworks to Full-Stack Platforms > Source: > Published: 2026-09-23 10:22:21+00:00 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?** 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. 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: 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. ``` 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. ``` 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. A platform provides most of the infrastructure as one system. This is the approach Minns takes. Ignore the branding and look at the requirements: Most frameworks solve some of these. Very few try to solve all of them in one environment. 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. 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 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'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 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 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 (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: It's a connectivity layer. A platform can use MCP without being replaced by it. **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: **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. `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. 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. ``` ┌──────────────┐ │ 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. **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: The GenAI conventions are still evolving, so expect attribute names to shift, but the direction is clear: agent telemetry is becoming standard telemetry. Traces tell you what happened, not whether it was good. Judging turns runs into signal, usually by combining: 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. **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: 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: This is why APO belongs inside a loop with judging, validation and approval, not as a script someone runs occasionally. 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. Minns treats optimisation as part of the platform rather than a separate tool. The loop above runs inside it: 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. 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. 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:** **Consolidating on a platform makes sense when:** 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. 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. 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. No. MCP is a protocol for connecting AI applications to tools and data. It standardises connectivity, not agent behaviour, memory, execution or governance. 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. 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. 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. 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](https://minns.ai).*