Agentic infrastructure: the skills, tools, sandboxes and controls that let AI agents do real work safely

From chat window to infrastructure

An agent is a model in a loop: it reads a goal, decides on a step, calls a tool, looks at the result and repeats. That loop is easy to demo and hard to run at scale. Once agents touch real systems, the same questions come up in every company: how does the agent know how we do things here, what is it allowed to touch, where does its code run, whose authority is it acting on, and how do we find out what it did? Each question maps to a layer of infrastructure, and in 2026 most layers have an emerging standard.

Skills: packaged know-how, loaded when needed

A skill is a folder with a SKILL.md file: a short name and description, then instructions, optionally alongside scripts, templates and reference documents¹. The agent sees only the names and descriptions up front and reads the full skill when a task calls for it, so a company can give an agent hundreds of procedures without filling its context window¹. Anthropic published the format as an open specification, and many agent tools now read the same files².

For a business, skills are the natural home for "how we do things here": how to write a release note, how to reconcile a payment file, which checks to run before changing a database. They are also where tool automation becomes reliable. If a step is deterministic, put a script in the skill and tell the agent to run it, rather than letting the model regenerate the logic each time. The model handles judgement; code handles the parts that must be the same every time.

Treat skills as code. A skill can contain scripts that run with the agent's permissions, so a skill from the internet deserves the same scrutiny as a dependency. Keep company skills in version control, review changes, publish them through an internal registry and only allow approved sources. See running an enterprise MCP sub-registry for the same pattern applied to tools.

Tools: what the agent can actually do

Tools are how agents act: query a database, open a ticket, send a message, deploy a change. The Model Context Protocol has become the common way to expose them, and its 2026-07-28 specification made the protocol core stateless and added a formal extensions framework, which makes MCP servers easier to run behind ordinary load balancers³. See the MCP stateless migration playbook.

Design tools for agents, not for humans. Fewer, task-shaped tools ("create refund up to a limit") are safer and easier for a model to use than thin wrappers around every API endpoint. Mark which tools only read and which change things, and require approval for the ones that are hard to undo. The MCP server security checklist covers the details.

Execution: sandboxes and workflows

Agents that write and run code need somewhere disposable to do it. The Kubernetes Agent Sandbox project, under SIG Apps, adds a Sandbox resource for isolated, stateful, single-instance workloads, with support for runtimes such as gVisor and Kata Containers, scale to zero when idle and warm pools to avoid cold starts⁵. That fills a real gap: an agent's workspace looks nothing like a stateless web service. See scale to zero on Kubernetes for the cost side.

Isolation is necessary but not sufficient, as the CNCF has argued⁶. A perfectly isolated sandbox holding a broad API key can still do damage through that key. Pair sandboxes with limited outbound network access, short-lived credentials scoped to the task, and monitoring of what leaves the sandbox; see agent sandboxing lessons and prompt injection defence.

Long-running work also needs a workflow layer: durable queues, retries, timeouts and human approval steps that survive restarts. Let the workflow own the order of steps that must always happen, such as "approve before payment", and let the agent work inside each step.

Control: identity, policy and a stop button

Every action an agent takes should answer two questions: which agent did it, and on whose authority. The MCP Enterprise-Managed Authorization extension, now stable, lets organisations grant MCP server access centrally through their identity provider, scoped to users' groups and roles, instead of each user authorising each server⁴.

On top of identity, define policy per agent: which tools, which data, what spending or volume limits. And keep a stop button: a way to pause one agent, or revoke its credentials, in seconds. See the 4 November tech news on agent kill switches.

Evidence: telemetry, evaluations and cost

OpenTelemetry's generative AI semantic conventions define spans for agent invocations and tool executions alongside model calls, so a single trace can show what the agent was asked, which tools it called and what each cost in time and tokens⁷. Use them from the start; retrofitting telemetry onto agents in production is painful. Then run evaluations on real tasks whenever a model, skill or tool changes; see evaluating AI agents.

What to build, in order

CTO take

The interesting work in agentic AI has moved from the model to the infrastructure around it. Skills turn tacit company knowledge into something an agent can use and a reviewer can read. MCP makes tools portable. Sandboxes and workflows make execution safe and durable. Identity and telemetry make the whole thing governable. None of these needs a large platform team to start: a registry of approved skills and tools, agent identities in your existing identity provider and OpenTelemetry on every call will take most teams a long way. For how far to let agents run unattended, see dark factories and automating work, and for a worked example, the enterprise MCP agent platform case study.

How I can help

I design agent platforms: skills and tool registries, sandboxed execution, identity and policy, and the telemetry that shows what agents actually do. I am based in India, the United States and the UAE, working globally. See AI architecture, where I work, or analyse your challenge and bring the result to a call.