Why We Built Our Platform: The Architecture Behind Enterprise-Grade Agentic AI

The agentic AI landscape in March 2026 is simultaneously thriving and on fire. Every enterprise wants agents. Few can deploy them safely. The gap between “demo” and “production” is where companies lose millions, leak credentials, and violate regulations they didn’t know applied to them yet.

This post is a technical deep-dive into how our platform solves these problems at the architecture level. We’ll walk through each core mode — CodeMode, ChatMode, and Flows — show real code from our platform, and explain why every design decision maps to a specific industry pain point that emerged over the last twelve months.

The State of Agentic AI: March 2026

Before diving into architecture, it’s worth understanding why the industry needs platforms like ours right now. The numbers paint a stark picture.

Gartner predicts 40% of enterprise applications will feature AI agents by end of 2026, up from less than 5% in 2025 — an 800% increase. A CrewAI survey found 100% of enterprises plan to expand agentic AI in 2026. Yet only 21% have a mature governance model for autonomous agents (Deloitte State of AI 2026). And Gartner separately predicts over 40% of agentic AI projects will be canceled by end of 2027 due to escalating costs, unclear business value, or inadequate risk controls.

Translation: everyone is building agents, almost nobody has governance, and a massive wave of project failures is coming. This is the environment our platform was built for.

The Five Problems Nobody Else Solves Together

The competitive landscape is crowded. LangChain, CrewAI, Microsoft Agent Framework, AWS Bedrock AgentCore, Salesforce Agentforce — every major player has an agentic offering. But each addresses a slice of the problem. Here’s what enterprises actually need, and where the gaps are:

LangChain gives you a framework. CrewAI gives you multi-agent collaboration. AWS Bedrock AgentCore gives you serverless runtime. Salesforce Agentforce gives you CRM-native agents. None of them give you all five requirements in a single platform with a unified security model.

Our platform does. Here’s how each mode works.

CodeMode: Persistent AI-Assisted Development

CodeMode is not “ChatGPT with a terminal.” It’s a persistent, session-based development environment where an AI assistant maintains context across conversations, executes code in isolated sandboxes, and has direct access to MCP tools for real-world operations (Git, Docker, Kubernetes, cloud CLIs).

Automatic Context Windowing

Every AI coding tool eventually hits the context limit. When it does, most tools either truncate silently or force you to start a new conversation. CodeMode handles this with automatic context compaction:

The result: CodeMode sessions can run indefinitely without losing context. The AI remembers what you worked on three hours ago because the compacted summary preserves key decisions, file paths, and architectural context. Every message is persisted in the database with full token accounting, so you can resume sessions days later.

Workspace Isolation

Every CodeMode session gets its own PTY (pseudo-terminal) in an isolated container via the agenticode-exec service. Each user gets:

Dedicated container with configurable CPU, memory, and storage limits
Network policy enforcement — containers can only reach approved endpoints
Incremental workspace snapshots to S3, Azure Blob, or GCS with optional encryption
Execution tracking — every shell command, file edit, and file read is logged with exit codes, stdout/stderr, and timing

This matters because the alternative — running AI-generated code on your local machine or a shared server — is how credentials leak, files get corrupted, and lateral movement attacks begin.

ChatMode: A 10-Stage Modular Pipeline

ChatMode is where general-purpose AI conversations happen. But unlike a simple LLM API wrapper, ChatMode routes every message through a 10-stage pipeline. Each stage is independent, configurable, and can be enabled or disabled per deployment.

Why does this matter? Because every stage addresses a specific failure mode that enterprises hit in production:

Stage 2 (Validation) prevents prompt injection — the #1 attack vector against AI agents in 2026
Stage 3 (RAG) grounds responses in your actual knowledge base, reducing hallucinations
Stage 6 (MCP) uses semantic indexing, not keyword matching — the LLM sees only relevant tools, not a menu of thousands
Stage 10 (Response) writes a SHA-256 chain-hashed audit entry for every interaction, which we’ll cover in the security section

Semantic Tool Selection

This deserves special attention. Most MCP implementations give the LLM a flat list of every available tool. With 10+ MCP servers, that means hundreds of tool definitions consuming context tokens and confusing the model.

The platform’s MCP Stage uses semantic indexing: tool definitions are embedded into a vector store, and only tools semantically relevant to the user’s intent are passed to the LLM. If you ask about Azure VMs, you don’t see Slack tools. This is the same principle behind Anthropic’s Tool Search feature released in early 2026 — the same semantic-tool-selection approach our MCP Stage is built around.

Flows: DAG-Based Workflow Orchestration

Single-turn chat and code sessions are useful. But enterprise AI workloads are multi-step: ingest data, transform it, run it through an LLM, validate the output, get human approval, then execute against a production system. That’s a workflow, and it needs an engine.

Flows is a DAG-based (directed acyclic graph) workflow execution engine. Each workflow is a graph of typed nodes connected by edges, with built-in error recovery, secret management, and cross-framework orchestration.

Error Recovery at Every Node

Every node in a workflow can have its own error recovery configuration. This is not a global retry policy — it’s per-node, because an LLM call needs different recovery than a database query.

Why circuit breakers matter for AI workflows: if an LLM provider is down, you don’t want 500 workflow executions hammering the same dead endpoint. The circuit breaker opens after 5 failures, routes traffic elsewhere (via SmartModelRouter failover), and periodically tests recovery.

Cross-Framework Orchestration

Here’s something no other platform offers: our platform’s workflows can orchestrate across agent frameworks. A single workflow can call a CrewAI crew, feed its output into a LangGraph workflow, and pipe the result through an MCP tool — all with shared credentials, audit trails, and error recovery.

This matters because Microsoft merged AutoGen and Semantic Kernel into the Microsoft Agent Framework, and enterprises are now running multiple agent frameworks in production. You need an orchestration layer that doesn’t care which framework built the agent.

Multi-Agent Orchestration: How Agents Work Across the Platform

A common question in 2026: “Do you support multi-agent workflows?” The answer is yes — but more importantly, agents in our platform aren’t a bolt-on feature. They’re structural. Every mode in the platform uses agents, and they coordinate through shared infrastructure rather than ad-hoc message passing.

Here’s how agents are used in each mode:

ChatMode: Background Agents and Sub-Agent Spawning

ChatMode’s Stage 7 (Agents) can spawn sub-agents for background work. When a user asks a question that requires multiple steps — research a topic, synthesize findings, and draft a response — the primary agent can delegate sub-tasks to specialized agents that run concurrently. Each sub-agent:

Gets its own LLM context window (no context pollution between agents)
Inherits the user’s credential scope (cannot escalate permissions)
Has all tool calls DLP-scanned independently
Writes to the same audit trail as the parent agent
Returns structured results that the primary agent synthesizes into the final response

CodeMode: Persistent Agent Sessions

CodeMode agents are long-running. They maintain state across conversations, remember file edits, track build errors, and can resume work after being idle. When a CodeMode agent needs to execute code, it uses its dedicated PTY sandbox. When it needs external data, it uses MCP tools. When no pre-registered tool exists for a task, it can synthesize one via OATS — with human approval before execution.

Flows: Multi-Agent DAG Execution

In Flows, each node can be an independent agent. A single workflow might:

Every agent in this pipeline shares the same credential scope, DLP rules, and audit trail. The DAG engine handles retries, circuit breakers, and fallbacks at each node. If the Analysis Agent fails, it doesn’t crash the workflow — the error recovery config for that node kicks in.

Cross-Framework Agent Integration

Some open-source agent frameworks offer multi-agent collaboration as their core value proposition — role-based agents, hierarchical delegation, shared memory. The platform already provides all of this functionality natively, plus what those frameworks lack:

The key difference: standalone agent frameworks give you the orchestration but leave security, governance, and infrastructure as your problem. The platform gives you orchestration inside a system that already handles credential isolation, DLP, audit trails, and multi-provider routing. You can still use those frameworks inside Flows — a workflow node can execute a CrewAI crew or a LangGraph workflow — but the governance layer wraps everything uniformly.

You don’t need a separate agent framework when your platform is the agent framework.

SmartModelRouter: Dynamic, Feedback-Driven Model Selection

We’ve written about SmartModelRouter before, but the system has evolved significantly. Here’s the current architecture.

Feedback-Driven Scoring

Most model routers score based on static benchmarks. SmartModelRouter learns from your team’s actual usage. Every 30 minutes, it ingests user feedback (thumbs up/down, copy, share, regenerate, report) from the last 30 days and adjusts model scores by -15 to +15 points based on satisfaction.

If your team consistently prefers Claude Sonnet over GPT-4o for code generation tasks, SmartModelRouter learns that and starts routing code requests to Sonnet automatically. No configuration required.

The Intelligence Slider

SmartModelRouter exposes a cost-quality tradeoff via the Intelligence Slider (0-100). At position 30 (cost-focused), Ollama and economy models get massive score boosts. At position 80 (quality-focused), frontier models like Claude Opus dominate. The math is simple:

Cost weight = 0.5 + (50 - sliderPosition) / 100
Quality weight = 0.5 + (sliderPosition - 50) / 100

This lets teams trade cost for quality at the organizational level. A dev team running automated code reviews can set slider=30 and use self-hosted Ollama models at zero marginal cost. A compliance team reviewing contracts sets slider=90 and gets frontier reasoning.

The Security Architecture

Security is where the platform is most differentiated. The numbers from 2026 are alarming:

According to VentureBeat, deploying just 10 MCP plugins creates a 92% probability of exploitation. 30 CVEs were filed in 60 days. Dark Reading reports that even Microsoft and Anthropic’s own MCP servers are at risk of takeover. And only 29% of organizations report being prepared to secure agentic AI deployments.

The platform addresses this with four layers of security built into the platform core — not bolted on as optional middleware.

Per-Tool Credential Scoping

This is the most important security feature in the platform. By default, if a user authenticates via Azure AD, every MCP tool could receive their full access token. That token can access Azure Resource Manager, Microsoft Graph, SharePoint, email — everything the user can do.

The platform’s CredentialScopeService limits each tool to only the credentials it needs:

If a compromised MCP tool tries to access Microsoft Graph when it was only scoped for Azure ARM, the request fails. The credential was never available. This is defense-in-depth at the credential layer — even if an attacker achieves code execution inside a tool, they can only reach the specific API surface that tool was authorized for.

DLP Scanning: 50+ Patterns, 4 Scan Points

The DLP scanner runs at four points in the data flow: tool input (before execution), tool result (after execution), LLM output (before sending to user), and user input (when the user sends a message). Every scan checks 50+ patterns across five categories:

Credentials (20 rules): AWS keys (AKIA...), GitHub tokens (ghp_...), Slack tokens, database connection strings, private keys, generic API keys
PII (15 rules): SSNs, credit cards (with Luhn validation), email addresses, phone numbers, passport numbers, IBANs
Infrastructure (10+ rules): IP addresses, AWS ARNs, IAM role ARNs, Kubernetes secrets
Compliance patterns: HIPAA identifiers, financial data markers
Injection detection: SQL injection, command injection, path traversal

Severity determines the action: low = allow with logging, medium = redact sensitive portions, high/critical = block execution entirely.

The Competitive Landscape: Where Everyone Else Falls Short

Let’s be specific about how the platform compares to what shipped in Q1 2026:

The Protocol Wars: MCP + A2A + OATS

The Agentic AI Foundation (AAIF) launched in December 2025, co-founded by OpenAI, Anthropic, and Block under the Linux Foundation. Three anchor projects: Anthropic’s MCP, Block’s Goose, and OpenAI’s AGENTS.md. Google’s A2A protocol handles agent-to-agent communication. MCP handles agent-to-tool communication.

The platform was an early MCP adopter and is now building A2A support. But we also built something neither protocol addresses — and it solves the single biggest pain point in the MCP ecosystem.

The MCP Problem Nobody Wants to Talk About

MCP promised universal tool interoperability. The reality in March 2026 is different. Building an MCP server requires writing exact JSON-RPC schemas, implementing transport layers, handling authentication, managing lifecycle, and testing against every client. Using community MCP servers is worse: 38% lack authentication entirely, 72% expose sensitive capabilities without scoping, and deploying 10 plugins creates a 92% chance of exploitation.

The ecosystem has created a perpetual cycle:

This is not a protocol problem — MCP is a fine specification. It’s an ecosystem problem. The gap between “a protocol exists” and “production-ready tools exist for every API I need” is enormous, and enterprises are burning engineering months filling it manually.

OATS: The Solution to the MCP Integration Problem

OATS (On-demand Agent Tool Synthesis) breaks the cycle entirely. Instead of searching for pre-built MCP servers, hoping they work, or spending days writing your own — you describe what you need in natural language, and the LLM synthesizes a working tool in seconds.

The key insight: most tool use is ephemeral. You don’t need a permanent, maintained MCP server to check a Bitcoin price, fetch a weather forecast, query a REST API, or scrape a webpage. You need code that works right now for this specific request. OATS generates that code, shows it to you for approval (human-in-the-loop), executes it in a sandbox, and returns the result. No schemas to maintain. No servers to deploy. No stale dependencies to patch.

For tools you use repeatedly, MCP is the right answer — register once, use forever. For everything else, OATS eliminates the integration tax entirely. It’s the third leg of the protocol stool: MCP for registered tools, A2A for agent coordination, OATS for on-demand tool creation.

The Regulatory Cliff: August 2, 2026

Full EU AI Act enforcement for high-risk AI systems begins August 2, 2026. That’s less than five months away. Requirements include quality management systems, risk management frameworks, technical documentation, conformity assessments, and — critically — requirements around record-keeping, transparency, human oversight, accuracy, robustness, and cybersecurity.

Penalties: up to 35 million euros or 7% of global revenue.

The platform’s cryptographic audit trail was designed for exactly this regulatory environment. Every interaction is chain-hashed with SHA-256, making the audit log tamper-evident by mathematical proof, not by policy. You can export to any SIEM system. Human-in-the-loop approval gates in Flows provide the “human oversight” the Act requires. DLP scanning provides the “cybersecurity” controls. The Intelligence Slider provides the “transparency” — organizations can see exactly which model handled which request and why.

In the US, Colorado’s AI Act takes effect June 30, 2026. The regulatory window is closing fast, and platforms without built-in governance will leave their customers exposed.

What We’re Building Next

The platform is not done. The roadmap for Q2 2026 includes:

A2A Protocol Support: Agent-to-agent coordination across organizational boundaries
MCP Apps Integration: Interactive UI components returned from tools, following Anthropic’s MCP Apps specification
Expanded OATS Capabilities: More built-in capabilities and a capability marketplace
EU AI Act Compliance Package: Automated conformity assessment generation from audit trail data
Multi-Region Deployment: Run agents in the geographic region closest to data sovereignty requirements

Getting Started

Our platform is available now. It runs on your infrastructure — Kubernetes, Docker, or bare metal — with no data leaving your network. OATS is part of the platform.

Sources cited in this article: Gartner AI Agents Prediction, CrewAI Enterprise Survey, Deloitte State of AI 2026, Gartner Project Cancellation Prediction, VentureBeat MCP Security, Dark Reading MCP Takeovers, Help Net Security Agent Risks, Linux Foundation AAIF, Google A2A Protocol, EU AI Act August 2026 Deadline, The Register MCP Apps, Anthropic Advanced Tool Use, Microsoft Agent Framework, MetricStream AI Regulations.