Enterprise AI-Agent Platforms and Frameworks 2026

Executive verdict

The state of the art is not one winning framework. It is a layered architecture in which managed platforms provide runtime, identity, context, evaluation and operations; developer frameworks provide agent and workflow semantics; MCP and A2A provide interoperability; and the enterprise remains responsible for truth, permissions, evaluation, incident response and controlled learning [src-251, src-252, src-254, src-255].

BMAD belongs above this stack as a software-delivery methodology and workflow builder. It can improve discovery, architecture and artefact continuity, but it is not an enterprise agent runtime or control plane ^[src-253].

Ten key takeaways

1. Category discipline matters. Methodologies, SDKs, orchestration runtimes, managed platforms and protocols solve different problems.

2. Durability is the dividing line between demos and operations. Consequential agents need checkpoints, idempotency, cancellation, compensation and replay-aware side effects.

3. Enterprise context is primarily an identity and provenance problem. More retrieval does not create safer knowledge.

4. Memory is behaviour-shaping state, not verified truth. Shared memory needs permissions, provenance, freshness and supersession ^[src-259].

5. Multi-agent is a task-specific architecture choice. It helps decomposable parallel work and can harm sequential or tool-heavy tasks [src-257, src-258].

6. Central coordination usually contains errors better than free-form peer interaction. It still adds latency, tokens and failure surfaces [src-256, src-257].

7. MCP and A2A are complementary plumbing. They standardise exchange, not competence, trust or governance ^[src-254].

8. The major managed platforms are converging on the same primitives. Differentiation increasingly comes from native data, identity, workflow and control-plane integration ^[src-251].

9. “Learning” must be a promotion pipeline. Feedback should produce evaluated, approved and reversible changes rather than autonomous rewriting [src-255, src-259].

10. No vendor currently removes the need for enterprise architecture. Preview status, ecosystem lock-in and immature evaluation remain material constraints.

Scoring method

Scores assess documented capability as of 23 July 2026:

• 3 — strong native capability: clearly documented as a central product feature.
• 2 — partial or mixed maturity: native capability exists but is limited, preview, fragmented or dependent on adjacent products.
• 1 — external assembly required: possible through integrations or application code.
• 0 — no credible current evidence.

A score is not proof of comparative performance. Vendor documentation establishes product scope; independent reliability evidence remains sparse [src-251, src-252].

Managed platforms: construction and execution

Managed platforms: enterprise operations

Managed-platform interpretation

• Microsoft offers the broadest low-code/pro-code continuum and strong Entra-based identity. Its strongest benefits are Microsoft-native, and several hosted-agent, memory and A2A features have mixed GA/preview status ^[src-251].
• Google has the clearest integrated build-scale-govern-optimise narrative, strong Memory Bank, evaluation and protocol support. The renamed 2026 platform remains operationally Google Cloud-centred ^[src-251].
• AWS exposes the most modular control-plane decomposition: Runtime, Harness, Memory, Gateway, Identity, Observability, Evaluations and Optimization. This is powerful but leaves architecture choices to the adopter ^[src-251].
• IBM emphasises governed enterprise orchestration and regulated environments; public technical and price transparency remains weaker than the hyperscalers ^[src-251].
• Salesforce is compelling for CRM and Data Cloud workflows. Its context advantage and its lock-in are two sides of the same design ^[src-251].
• ServiceNow is distinctive as a workflow-native platform plus cross-platform AI inventory and governance hub. Evidence for transactional agent-memory semantics is less explicit ^[src-251].

Developer frameworks: construction and execution

Developer frameworks: enterprise operations

Framework interpretation

• LangGraph: strongest low-level open orchestration runtime for durable, explicit graphs; requires engineering discipline around replay and side effects ^[src-252].
• Microsoft Agent Framework: strongest enterprise-oriented SDK surface, combining AutoGen and Semantic Kernel lineage with typed workflows and telemetry; the unified API is still relatively new ^[src-252].
• Google ADK: strongest open protocol and context-engineering story; managed operations naturally favour Google Cloud and A2A remains operationally young ^[src-252].
• OpenAI Agents SDK: smallest comprehensible loop with excellent guardrails and tracing; sessions are not a durable workflow engine ^[src-252].
• CrewAI: productive role-based automation with a useful Flow layer; uncontrolled crews can add agents without adding evidence ^[src-252].
• LlamaIndex: strongest context and retrieval layer in the group; combine it with a durable runtime for consequential workflows ^[src-252].
• Strands Agents: broad graph, workflow, swarm, MCP and A2A primitives; younger state and telemetry behaviour needs rigorous failure testing ^[src-252].
• BMAD: strong delivery method and artefact discipline; runtime identity, security, observability, scaling and incident response are out of scope ^[src-253].

When multi-agent helps

• Independent parallel sub-problems with verifiable outputs.
• Specialised tools, data boundaries or permissions.
• Context isolation that genuinely reduces interference.
• Independent critique using different evidence or methods.
• Cross-enterprise delegation where separate agents preserve organisational boundaries.

The scaling evidence reports large gains on a decomposable financial-reasoning task, but this is a task-specific benchmark—not a general multi-agent uplift ^[src-257].

When multi-agent hurts

• Sequential work with strong dependencies.
• Tool-heavy tasks where orchestration adds more calls than useful reasoning.
• Tasks where a strong single-agent baseline is already near saturation.
• Teams using the same model, context and assumptions while claiming independent review.
• Free-form debate without a verifier.
• Consequential work without durable state, authority and rollback [src-256, src-257, src-258].

The MAST study finds recurring system-design, inter-agent-alignment and verification failures across seven frameworks ^[src-256]. The scaling study finds outcomes ranging from substantial gains to severe degradation depending on task and topology ^[src-257].

Current limitations

Build, buy or combine

Buy a managed platform when

• the organisation is already standardised on the vendor's identity, data and workflow estate;
• regulated operations need managed deployment, audit and support;
• platform engineering capacity is limited;
• low-code participation is important.

Build on an open framework when

• agent behaviour and orchestration are differentiating intellectual property;
• portability and custom deployment matter;
• the team can operate state, identity, telemetry, policy and incident controls;
• workflows cross several clouds or systems.

Combine both when

• custom agent logic is needed but the enterprise wants managed identity, scaling and monitoring;
• an open framework runs inside Foundry, Agent Runtime or AgentCore;
• LlamaIndex or another context layer is paired with a durable workflow runtime;
• BMAD governs the software-delivery process while a runtime executes the resulting agents.

Avoid an agent framework when

• deterministic code or ordinary workflow automation solves the task;
• one strong agent with tools meets the quality bar;
• there is no durable business owner, evaluation dataset or rollback path.

Minimum viable control plane

The irreducible foundation is:

• agent, model and tool registry;
• end-user and workload identity;
• policy enforcement and credential brokering;
• durable orchestration;
• tenant-aware context gateway;
• governed memory;
• approval and external-effect ledger;
• distributed traces and cost accounting;
• versioned evaluation;
• incident response, kill switch and rollback [src-254, src-255, src-259].

See Enterprise Agent Platform Stack for the complete eight-layer reference architecture and Governed Enterprise Agent Learning for the safe learning lifecycle.

12–24 month outlook

Durable trends

• Managed runtimes become framework-agnostic while retaining cloud-native identity and operations.
• MCP becomes normal for tool access; A2A adoption grows for cross-agent tasks.
• Agent identity, registries and gateways become standard control-plane components.
• Evaluation moves from offline response grading towards trajectory, access, cost and business-outcome testing.
• Shared memory becomes a governance domain rather than a convenience feature.
• Strong systems route between deterministic code, single-agent and multi-agent execution.

Claims to treat cautiously

• “Agent of agents” positioning without durable task semantics.
• Swarms presented as inherently more intelligent.
• Protocol support marketed as interoperability without security and operational proof.
• Memory marketed as learning without provenance and promotion controls.
• Vendor benchmarks that give agent systems more models, calls or tokens than the baseline.
• Roadmaps presented as shipped enterprise capability.

Source references

• ^[src-251] Enterprise managed AI-agent platforms official documentation bundle
• ^[src-252] Enterprise agent frameworks official documentation bundle
• ^[src-253] BMAD Method v6.10 and BMad Builder enterprise customisation
• ^[src-254] MCP and A2A protocol specifications
• ^[src-255] NIST AI RMF and EU AI Act controls
• ^[src-256] Why Do Multi-Agent LLM Systems Fail?
• ^[src-257] Towards a Science of Scaling Agent Systems
• ^[src-258] Single-agent or Multi-agent Systems? Why Not Both?
• ^[src-259] Collaborative Memory
• ^[src-260] Multi-Agent Risks from Advanced AI