Post

Designing the Agent Platform: One Loop, Owned Skills, Rules in Code, Gated Tools

One agent loop with owned skills, rules in code, eval-gated skill releases and gated MCP tools: platform designs from Anthropic, Salesforce, AWS, Uber and Google.

Posted Updated
By Imrul Sheikh
8 min read
Designing the Agent Platform: One Loop, Owned Skills, Rules in Code, Gated Tools

Write-ups from Oct 23–29 converge on one platform shape: a single agent loop that loads team-owned skills on demand, business rules that run as code rather than prompt text, and tools that sit behind a gateway where they start disabled. Production MCP data from the same week shows what those tools look like once they ship.

Part of This Week in AI & Systems #3: Rules in Code, Controls in IAM.

What’s new this week

  • Anthropic (Oct 22, the day before this issue’s window; not covered in #2) advised folding subagents back into one agent loop and published a migration kit. Microsoft Research’s Agensh (MarkTechPost, Oct 24; the paper and repository predate the window) is the counterpoint: up to 1,024 peer agents with no lead agent.
  • Salesforce (ByteByteGo, Oct 26) and LinkedIn (InfoQ, Oct 26) explained why rules and control flow moved out of prompts and into code.
  • AWS (Oct 28) published an open-source blueprint for an enterprise agent platform on Bedrock AgentCore.
  • Uber’s MCP Gateway was revisited by ByteByteGo (Oct 28), and Google (Oct 28) described the release pipeline behind more than 170 Agent Skills.
  • Production MCP data (InfoQ, Oct 26): schema sizes and annotation rules from ChatGPT’s plugin directory, and the stateless MCP C# SDK 2.0.

Why it matters. A platform where each product team wants its own agent must decide whether teams contribute subagents or skills, where hard rules live, and who approves a tool before agents can call it. This week’s posts answer all three.

Key ideas

One loop, owned skills

  • Don’t copy the org chart. Anthropic names the anti-pattern: each team ships its own subagent and adds rules until the system prompt contradicts itself. The suggested baseline is one clear system prompt, four or five thin data tools, firm output guardrails, tool search instead of loading every tool, and a small central team that owns the prompt. Tool selection reportedly degrades beyond 30 to 50 tool definitions. In one comparison, the single-agent version ran about twice as fast.
  • Subagents still have a place. The same post keeps them for cases where context bloat measurably hurts, where tasks need parallel fresh contexts, or where tool selection fails. It also warns against merging blindly: in one support-agent test, folding in a subagent cut latency but broke a working hand-off.
  • Many peers can also win. Agensh points the other way for some workloads. On the hardest ProgramBench tasks, it raised mean test-pass rates from 19.3% with one agent to 28.8% with 128 (results as reported by MarkTechPost).
  • Skills are releases. Google’s Agent Skills repository now holds more than 170 skills and has passed 21,000 GitHub stars. Every change must pass structural and lint checks, a mandatory semantic version bump for any behaviour change, an evaluation report against the previous version (or against no skill at all for a new one), link validation, an AI review agent and finally a human expert’s approval. The reasoning: a skill steers an agent’s tool choices, so a wording change is a behaviour change.

Rules in code

  • Prompts drop rules. According to ByteByteGo’s interview, the first Agentforce put every rule into one prompt, and the model began dropping instructions beyond about eight. In the redesign, Agent Script, an open-source, Python-like language, compiles to an Agent Graph whose before_reasoning and after_reasoning blocks always run as code.
  • Each job gets its own system. Data 360 resolves identities with match rules. An Agent Context Engine chooses what reaches the model, which cut one insurance query from 124,000 to 9,000 tokens. Agent Identity gives each agent its own permissions.
  • Choose the least complex harness. Ramgopal’s advice in InfoQ: treat LLM output as untrusted input, separate planning from execution, and pick the least complex harness that is good enough.

Gated tools

  • Registry as control plane, proxy as data plane. Uber’s MCP Gateway, AutoCrawler, disabled-by-default tools and owner approval were covered in #1’s control plane post. ByteByteGo’s write-up adds the split: an MCP Registry holds the catalog of servers and tools and decides what is enabled, and a Proxy Gateway routes live agent calls to services that speak HTTP, gRPC or TChannel. It also adds that the crawler runs on Cadence, that native MCP servers are detected by their heartbeat metric, and that approved definition changes can be rolled back.
  • Two gateways, one per traffic type. In AWS’s blueprint, every inference request passes an inference gateway that applies guardrails, controls which models and regions each team can use, and enforces rate limits, token quotas and budgets. Tools are reached only through an authenticated MCP gateway with least-privilege roles and a named owner. Each team gets its own deployable cell and ships through a CI/CD evaluation gate.

What production MCP looks like

  • Small, annotated schemas. In ChatGPT’s plugin directory, about three in four tool schemas are under 1 kB, though some reach 260 kB. Oversized schemas get trimmed, and OpenAI rejects servers unless every tool carries annotations, so read-only calls can be fast-tracked and destructive ones confirmed.
  • Long-running calls and identity. Anthropic added MCP tasks to Claude Code for tool calls that run for hours or days, and reported 4.17 billion SDK downloads. Its auth roadmap has proof-of-possession tokens and workload identity federation in draft.
  • Stateless by default. Microsoft’s MCP C# SDK 2.0 implements the 2026-07-28 spec. Servers are stateless by default, with no handshake or session ID, and Mcp-Method/Mcp-Name headers let gateways route without parsing the body.

Diagram of an agent platform: team-owned, versioned skills are loaded on demand into one shared agent loop; rules in code run before and after the loop's reasoning; the loop sends tool calls through an MCP gateway whose tools start disabled, and model calls through an inference gateway with per-team quotas and budgets Diagram of an agent platform: team-owned, versioned skills are loaded on demand into one shared agent loop; rules in code run before and after the loop's reasoning; the loop sends tool calls through an MCP gateway whose tools start disabled, and model calls through an inference gateway with per-team quotas and budgets Composite of designs from Anthropic, Google, Salesforce, Uber and AWS; not any one source’s diagram. Tap to enlarge.

Analysis: read together, the posts suggest that teams contribute owned, versioned skills to one loop rather than shipping their own subagents, and that anything a team must guarantee (a business rule, a tool permission, a budget) moves out of prompt text into code, a gateway or a release gate. Open question: Anthropic’s evidence comes from enterprise deployments and Agensh’s from hard coding benchmarks, so where the crossover sits for a given platform still has to be measured; the migration kit is one way to test it before rewriting anything.

Reading list

Grouped loosely: agent shape (Anthropic, The Decoder, MarkTechPost), rules and harnesses (ByteByteGo, InfoQ), platform blueprints and tool gateways (AWS, ByteByteGo), skills as products (Google Cloud) and production MCP (InfoQ).

Background and prior art

AI & Agents, This Week in AI & Systems
agent-patterns mcp system-design
This post is licensed under CC BY 4.0 by the author.