Last week, two things happened that, taken separately, look like product launches. Taken together, they mark the emergence of a new layer in the software development stack.
On May 6, AWS launched the Agent Toolkit for AWS — a production-ready suite of tools, skills, and a managed MCP server designed to make AI coding agents competent at building on AWS. Not just able to generate CloudFormation templates, but to follow validated procedures for doing it correctly. Forty-plus skills at launch, covering infrastructure-as-code, storage, analytics, serverless, containers, and AI services. IAM-based guardrails. CloudWatch observability. Sandboxed code execution.
Days earlier, Cursor shipped the public beta of its Cursor SDK — a TypeScript library that exposes the full agent runtime (codebase indexing, semantic search, MCP support, skill definitions, subagent orchestration) as programmable infrastructure. The agents that lived inside an editor can now be invoked from CI/CD pipelines, backend services, or any other orchestrator. Each cloud execution runs in a sandboxed VM with a cloned repo, persists even if the calling machine goes offline, and can be inspected or taken over via Cursor's web interface.
Neither of these is a better chatbot. Both are infrastructure.
What Changed
For the past two years, the conversation around AI coding agents has been dominated by a single question: which model is best? GPT-5 vs. Claude vs. Gemini. SWE-bench scores. Token throughput. Context window size.
That question mattered when agents were fragile and every improvement in model capability unlocked new use cases. But we've crossed a threshold. The models are good enough to do real work — reliably, at scale, across complex codebases. The bottleneck has shifted from model capability to operational infrastructure.
Consider what actually goes wrong when an agent fails in production. It's almost never because the model can't reason well enough. It's because:
- The agent didn't have the right context about your AWS account configuration and created resources in the wrong region
- The agent hallucinated an API that doesn't exist in the version of the SDK you're using
- There's no audit trail of what the agent did, so you can't roll back cleanly
- The agent's execution environment wasn't isolated, so a bad code change corrupted shared state
- You can't run the agent programmatically from your CI pipeline because it only works inside an IDE
These are infrastructure problems, not model problems. And they're exactly what the new agent infrastructure layer is designed to solve.
The Three Pillars of Agent Infrastructure
What both AWS and Cursor are building — from different angles — converges on three capabilities that any serious agent deployment needs:
1. Validated Procedures, Not Just Tools
The old model: give an agent access to an API and let it figure out how to use it. This works for simple cases. It fails spectacularly for anything involving IAM policies, CloudFormation nesting, or data pipeline orchestration — domains where "close enough" creates security holes or broken infrastructure.
AWS's answer is skills — validated, up-to-date procedures that encode best practices. A skill for authoring CloudFormation templates doesn't just call the API; it follows AWS's own recommended patterns for resource naming, tagging, dependency ordering, and drift detection. Each skill was "rigorously evaluated" — AWS's words — to ensure agents complete tasks more accurately.
This is a direct application of the harness engineering principle I wrote about: constrain the solution space before the agent begins. A skill is a constraint that works with the agent rather than against it. Instead of preventing the agent from doing something wrong, it gives the agent a well-lit path to doing it right.
2. Observable, Governable Execution
An agent that runs in the shadows is a liability. Enterprise teams need to know what their agents did, when they did it, and whether it complied with policy.
The AWS MCP Server provides this out of the box: CloudTrail integration for auditing, CloudWatch for observability, IAM guardrails for access control. You can define exactly which AWS actions an agent is allowed to perform — not at the prompt level, where the agent might ignore the instruction, but at the IAM policy level, where the action is mechanically enforced.
Cursor's SDK takes a different but complementary approach. Its execution hooks let teams observe and control the agent loop programmatically — logging decisions, enforcing guardrails, implementing custom orchestration logic. Self-hosted workers keep code and execution within the organization's network. Every agent run is inspectable and resumable.
The pattern is clear: agent observability is becoming a first-class requirement, not an afterthought. If you can't audit what your agent did, you can't trust it in production.
3. Programmable Invocation
Perhaps the most significant shift is the move from interactive to programmatic agent use.
Until now, AI coding agents have been fundamentally interactive tools — you chat with them in an editor, iterate on the output, and manually integrate the result. This works for individual developers but breaks down at scale. You can't run 50 agents in parallel, each working on a different pull request, if every one of them needs a human sitting in front of an IDE.
The Cursor SDK makes agents callable. npm install @cursor/sdk, create an agent instance, send it a task, stream the response. Point it at a directory or a cloud environment. It goes to work. The agent gets a sandboxed VM, a clone of the repo, a configured development environment, and full codebase indexing for context retrieval. Subagents can be spawned for multi-step workflows.
This transforms agents from tools you use into infrastructure you deploy. A CI/CD pipeline can invoke an agent to review a PR, fix a failing test, or update documentation — all without human involvement. The agent becomes a service.
Why This Is a Layer, Not a Product
Calling this a "layer" rather than a "product" is deliberate. Products compete. Layers compose.
The AWS Agent Toolkit provides cloud-platform-specific infrastructure — skills for AWS services, managed MCP server, IAM governance. Cursor's SDK provides agent-runtime infrastructure — sandboxed execution, codebase indexing, programmatic access. They're not competing. They're complementary. You could invoke a Cursor SDK agent from your CI pipeline, and that agent uses AWS skills to provision infrastructure correctly.
This is the same pattern we've seen in every maturing technology stack:
- 2005–2010: Virtualization became infrastructure (VMware, Xen) → cloud platforms built on top (AWS EC2)
- 2013–2018: Containers became infrastructure (Docker) → orchestration built on top (Kubernetes)
- 2020–2023: LLM APIs became infrastructure (OpenAI, Anthropic) → agent frameworks built on top (LangChain, CrewAI)
- 2026: Agent runtimes are becoming infrastructure (Cursor SDK, AWS Agent Toolkit) → agent-first development platforms will build on top
Each layer abstracts the complexity of the previous one. You don't think about hypervisors when you launch an EC2 instance. You don't think about container runtimes when you deploy to Kubernetes. Soon, you won't think about agent loops, context management, or sandbox setup when you deploy an agent to write code.
The Governance Question Nobody's Answering
Mitch Ashley at The Futurum Group raised the right concern: "Enterprise buyers now evaluate Cursor as infrastructure. Platform teams will press on worker isolation, agent telemetry, and policy enforcement before these agents enter CI/CD. Teams deferring that evaluation inherit governance debt the moment agents start opening pull requests unattended."
He's right, and this is where most teams will stumble. The infrastructure exists now. The governance practices don't.
Here's what I think the minimum governance stack looks like for any team running agents in production:
- Agent permissions as code. Not prompt instructions — actual IAM policies, RBAC rules, or equivalent access controls that mechanically limit what agents can do. If your agent governance lives in a
system prompt, it's a suggestion, not a control. - Full audit trails. Every agent action logged, timestamped, and attributable. Not just for compliance — for debugging. When an agent breaks production at 3 AM, you need to know exactly what it did and why.
- Human-in-the-loop for high-stakes decisions. Agents can create resources, modify infrastructure, and merge code autonomously — but deploying to production, modifying IAM policies, or touching customer data should require explicit human approval.
- Agent-specific monitoring. Not just "did the task succeed" but tracking token costs, error rates, correction frequency, and drift from expected behavior patterns over time.
Most teams have none of this. The infrastructure layer's arrival means the "we'll figure out governance later" window is closing fast.
What This Means for Harness Engineering
Everything I wrote about in Harness Engineering — constrain, inform, verify, correct — now has infrastructure support. The harness isn't something you build entirely from scratch anymore. AWS gives you validated skills (constrain + inform). Cursor gives you observable, sandboxed execution (verify). The correction loop is still on you, but the scaffolding is there.
This doesn't make harness engineering less important. It makes it more important, because the bar just went up. When everyone has access to the same agent infrastructure, your competitive advantage is the quality of your harness — the constraints, context, and verification you layer on top of the platform.
The teams that figure this out first will have agents shipping production code autonomously within months. The teams that don't will be stuck treating AI like a fancy autocomplete, wondering why their agents keep hallucinating in the same ways.
The Takeaway
We've moved from "can AI write code?" to "can we trust AI to write code in production?" The answer to the second question isn't about better models. It's about better infrastructure. AWS and Cursor just shipped two important pieces of it.
If you're building with agents and you're still manually copy-pasting code from a chat window into your editor, you're doing it wrong. The infrastructure layer exists. Use it.