When a Coding Agent Becomes Infrastructure
Cursor's SDK exposed its agent harness as a programmable service, making the infrastructure around the model the more interesting product boundary.
Cursor introduced its TypeScript SDK on April 29, 2026. This issue covers that announcement in the following editorial week; it does not imply that the SDK was available earlier.
According to Cursor's official release post, the public-beta SDK lets developers invoke the runtime, harness, and models behind Cursor from TypeScript. An agent can run locally or on Cursor's cloud, connect to MCP servers, load repository skills and hooks, delegate to subagents, and surface a cloud run in Cursor's normal interfaces for inspection or takeover.
Those are announcement facts. The broader interpretation is that a coding agent stops being only a developer tool when another system can create, observe, and control its runs.
A prompt box has a user; infrastructure has callers
An interactive coding assistant can rely on the person at the keyboard to provide context and notice failure. A programmatic agent may be started by a CI job, an issue transition, an internal application, or another agent. It needs a contract that survives without a person watching every step.
That contract begins before the model call. The caller needs to choose a repository and revision, provide an identity, select an execution environment, and constrain which tools can act. During the run, it needs durable state, structured events, cancellation, timeouts, and a way to distinguish progress from completion. Afterward, it needs artifacts that can be reviewed and traced back to the request.
The model is important, but it is one replaceable component inside that system.
The harness becomes part of the product
Cursor described codebase indexing, search, MCP connections, skills, hooks, and subagents as features of the SDK's harness. That list illustrates why model-only comparisons are incomplete.
Two systems can use the same model and produce different results because they assemble context differently, expose different tools, or recover from failure in different ways. A harness decides what enters the context window, how a run is compacted, which permissions require approval, and what evidence appears in the final result.
Once a company builds automation on top of those decisions, the harness is no longer incidental. Its behavior is an application dependency.
That creates a normal platform tradeoff. Buying the harness can remove a large amount of work around sandboxes, sessions, model integrations, and interface handoffs. Owning more of the orchestration can provide tighter control over identity, data location, cost, and failure handling. Neither choice is universally correct.
Five questions before treating it as infrastructure
First, who is the actor? A run should have an identity distinct from the person or service that requested it. Logs should show who asked, what the agent did, and who approved any consequential action.
Second, where does code execute? Local, hosted, and self-managed workers have different trust boundaries. A useful platform should make the boundary explicit rather than treating “cloud” as a complete security model.
Third, what is durable? A long-running task needs stable identifiers, reconnectable event streams, and clear terminal states. If a dashboard refresh loses the only record of the run, it is still a demo surface.
Fourth, how is policy versioned? Repository instructions, skills, hooks, and tool definitions affect the result as much as application code does. They need review and change history rather than silent dashboard edits.
Fifth, what can be verified? A generated branch or pull request is an artifact, not proof. The system should retain the commands, checks, previews, and unresolved gates needed for a reviewer to decide whether the change is safe to merge.
Programmatic does not mean autonomous
The SDK announcement included examples such as CI failure investigation, repository maintenance, and agents embedded in internal or customer-facing products. Those are plausible categories described by Cursor, not evidence that every workflow should be automated end to end.
Programmatic access is valuable because it allows a team to place the agent at the correct stage of a process. It can prepare a diagnosis without deploying a fix, produce a branch without opening a pull request, or run checks without declaring acceptance. Human review can remain a deliberate part of the design.
That is the useful shift in the April release. A coding agent can now be called like infrastructure. The engineering work is to give that call the same discipline expected from any other production dependency: bounded authority, observable state, reproducible configuration, and evidence at the output.