Building the Agentic Runtime with mcp-agent-runtime-go
By Constantine Vassilev. May 19, 2025
A modular, composable execution layer that orchestrates model selection, intelligent prompt transformation, and real-time agent synthesis — designed in Go to power the infrastructure of agentic AI systems.
🤝 One of the earliest high-profile implementations of MCP in Go is the GitHub MCP Server, built in collaboration with Anthropic. This open-source Go server:
✦ Enables AI assistants to interact with GitHub through standardized MCP APIs
✦ Supports tasks like PR management, repo queries, and code review
Integrates directly into dev workflows (e.g., VS Code)
✅ This proves MCP in Go is not just theory — it's production-grade infrastructure.
✍️ How It Started for Me
In July 2023, I entered the Google Cloud Vertex AI Hackathon and built AIT-DiagramCodeX, an AI App on Google’s Vertex AI Cloud Platform. Out of 4,653 participants, it was selected as a Finalist. This was also the moment I wrote my first pre-MCP agentic runtime implementation in Go, using its native concurrency features to handle streaming inputs, parallel API inference, and lightweight agent steps. That experience solidified my interest in building dynamic, multi-model, composable AI systems.
By June 2024, that work evolved into a Top 10 finish at the Microsoft Developers AI Learning Hackathon (9,527 participants), where I introduced ASAP (Advanced Semantic AI Platform) — a semantic agentic layer combining GPT and vCore-based Azure Cosmos DB for MongoDB. ASAP integrated reliable backend infrastructure with intelligent code/documentation generation.
Then in January 2025, I won Best Azure App Integration at the Microsoft GitHub & Azure Hackathon. The winning app: ASAP Knowledge Navigator — a runtime interface built on Retrieval-Augmented Generation (RAG) to extract and synthesize institutional knowledge in enterprise environments.
Those experiences led to the successful release of:
✅ Filing Navigator AI
Streamlined SEC Filings Research App Available on Microsoft AppSource
📤 Specification Submission
The next natural step: contributing to the core infrastructure layer powering these agentic tools.
I submitted the specification and architecture of this Go-based MCP runtime to the official MCP design thread:
🔍 Explanation by Component:
✦ Modular, composable execution layer → You can plug in only what you need: routing, prompts, agents, halting, metadata, tools. → Each part is a clean Go module — not a monolith.
✦ Model selection → Supports routing tasks to the most appropriate model (e.g., GPT-4o for reasoning, Claude for summarization), based on capability, trust, or latency.
✦ Prompt transformation → Raw input becomes structured, formatted prompts (e.g., few-shot, instruction templates, JSON modes). Handled dynamically at runtime.
✦ Real-time agent synthesis → Agents are constructed on-the-fly from task metadata — with declared tools, alignment policies, and halting controls.
✦ Written in Go → For performance, concurrency, and deployment efficiency — ideal for backends, orchestration servers, and dev-infra.
✦ To power the infrastructure of agentic AI systems → This is not a demo. It’s a foundation for building agent runtimes, developer copilots, composable ML services, and compliance-safe execution environments.
🧠 What Is MCP?
The Model Context Protocol (MCP) is a runtime coordination protocol — a structured way to describe, route, and execute intelligent tasks across models, agents, and tools.
It’s not an app. It’s not a wrapper. It’s the execution grammar beneath agentic AI.
MCP defines how to:
✦ Start and manage a session → Each task runs inside a lifecycle-managed session, with clear boundaries, metadata, and traceability (like tenant, user, or auth context).
✦ Describe what a model can do → Every model (GPT-4o, Claude 3.7, Gemini) has a ModelSpec: how many tokens it supports, what format it expects, whether it allows streaming, what tools or functions it supports, and what its latency profile looks like.
✦ Select the right model at the right time → A router can dispatch prompts based on task needs, policy rules, or trust levels. You don’t hardcode your model — you let MCP select it.
✦ Generate and execute agents → Agents are not static. MCP supports defining them dynamically: what tools they can access, how long they can run, what their alignment constraints are, and how they should respond under ethical boundaries.
✦ Apply safety and reproducibility controls → Halting policies prevent infinite loops. Descriptor hashes lock agent+model configurations for audit. Trust tiers control which models are allowed in which environments.
In short:
MCP gives structure to what LLM workflows already want to do:
• Compose
• Route
• Execute
• Trace
• Repeat
It’s not another framework. It doesn’t replace your favorite tools. It defines the common runtime contract that makes intelligent coordination modular, inspectable, and safe — across agents, models, and sessions.
MCP defines how to:
• Start and manage a session with traceable context
• Describe what a model can do (token limits, streaming, latency, trust)
• Route tasks across providers based on policy, capability, or alignment
• Dynamically generate agents with access to tools, halting, and policy
• Apply safety constraints and produce reproducible, auditable executions
It’s the difference between:
“I sent a prompt to a black box”
and
“I ran a task through an intelligent, verifiable, agentic runtime.”
🧰 What Is mcp-agent-runtime-go?
mcp-agent-runtime-go is a modular, idiomatic Go SDK that brings the Model Context Protocol (MCP) to life.
It’s not just a client. It’s not just a spec. It’s the runtime core that executes intelligent tasks the way modern AI workflows demand.
It provides a runtime substrate — not a monolith or framework. You wire together what you need. It handles:
• Model routing
• Prompt shaping
• Session metadata
• Dynamic agent creation
• Lifecycle and policy enforcement
Built for:
• Orchestration engines
• Dev agent stacks
• AI copilots
• Regulated AI environments
It’s the execution layer beneath intelligent coordination.
Designed for engineers building the infrastructure beneath the agents, this SDK gives you:
🔁 A Composable Runtime Layer
• You can wire together only what you need — nothing more, nothing less.
• You get interfaces, not a framework.
• You keep control over execution flow, safety policies, and lifecycle logic.
🧠 What It’s Built For
• Orchestration engines → Route prompts, pick models, transform templates, stream results. The SDK can power your intelligent backend.
• Dynamic agent generation → Agents are created on the fly from task descriptions, metadata, and system policy. You don’t need to predefine every agent — the runtime builds them.
• Safe, explainable, and auditable sessions → Every request runs in a structured session with full traceability. Execution can be sealed (DescriptorHash()), halted (HaltingPolicy), or restricted (alignment_policy).
• Multi-model coordination → Route to GPT-4o for reasoning, Claude for summarization, or Gemini for multimodal — based on model specs and trust levels.
🧱 Built the Go Way
• Lightweight
• Concurrent
• Easy to reason about
• Designed for production systems
This is not a heavy framework or a proprietary runtime. It’s a runtime substrate — the execution engine beneath your agent stack. You bring the policy, prompts, and intent. The SDK brings lifecycle safety, routing, and structure.
⚙️ Key Capabilities
Here’s what it gives you out of the box:
🧭 SessionLifecycle
What it does: Starts, tracks, and ends structured sessions with observability hooks. Why it matters: Everything in intelligent AI needs a scoped execution — like an HTTP request or container lifecycle. Sessions keep tasks isolated, auditable, and clean.
🧠 ModelRouter
What it does: Dynamically selects the best model (e.g. GPT-4o, Claude 3.7, Gemini) based on task type, trust tier, or performance profile. Why it matters: You don’t want to hardcode model selection. Let the runtime decide based on real constraints and goals.
📐 ModelSpec
What it does: Describes each model’s abilities: token limits, streaming support, input format, latency class, trust tier. Why it matters: Safer routing. Smarter dispatch. Prevents silent failures from sending a prompt to an incompatible model.
🧩 PromptOptimizerStep
What it does: Transforms raw input into optimized, task-specific prompt formats — including templates, few-shot examples, and system role conditioning. Why it matters: The same task can succeed or fail based on prompt quality. This layer brings structure and consistency.
🤖 AgentGenerator
What it does: Creates agent definitions on-the-fly from task context, tools, trust policies, and alignment constraints. Why it matters: Builds composable, adaptable agent workflows at runtime — without static configuration or brittle logic.
🛑 HaltingPolicy
What it does: Sets execution bounds: max steps, max time, recursion depth. Why it matters: Without halting, agents can loop forever or blow your budget. This ensures control and safety.
🔐 DescriptorHash()
What it does: Seals a session into a unique, hashable config — model, prompt, agent, metadata — for traceability. Why it matters: Makes every execution reproducible and auditable. Like a git commit hash for intelligent sessions.
🧰 ToolRegistry
What it does: Provides access to registered tools (e.g. search, RAG, database, code exec) that agents can call. Why it matters: Agents don’t just think — they act. This gives them a secure, structured way to invoke capabilities beyond the model.
🧱 alignment_policy
What it does: Specifies constraints (ethical, regulatory, behavioral) on what an agent can or cannot do. Why it matters: Gives developers and platforms a programmable safety layer — preventing undesired or dangerous behavior.
This isn’t just a toolkit — it’s a runtime spine. Every capability is designed to be:
✅ Optional if you want simplicity
✅ Extensible if you need power
✅ Auditable if you need trust