canter.dev

Inspiration

Agents can write code, but running what they build still pushes them toward either brittle shell access or infrastructure credentials that are far too powerful. We built Canter around a different boundary: the agent proposes an exact, inspectable Change; the human governs authority and high-impact execution; and the control plane produces evidence of what actually happened.

What it does

Canter is an agent-operated, human-governed hosting control plane. An agent can inspect a System, draft a Change, and review an immutable execution plan without receiving provider credentials. Every proposed deployment is bound to an exact digest, policy is explicit, apply can require human approval, and execution produces durable receipts.

For the WebMCP Challenge, Canter makes that workflow discoverable directly from the website. The site advertises same-origin agent discovery, provides WebMCP read and review tools, and points capable agents to the authenticated remote MCP contract for durable work. Browser tools cannot borrow the human session to bypass approval: a sensitive Change still needs a focused, short-lived review capability and an explicit human action.

How we built it

The control plane is written in Go with PostgreSQL-backed durable state. The product interface uses Next.js, React, and TypeScript. A typed System contract compiles into a deterministic execution graph before provider adapters can mutate infrastructure. The same semantic objects—Systems, Changes, exact digests, policy envelopes, operations, and evidence—are shared across the CLI, HTTP API, remote MCP, and WebMCP surfaces.

The website registers its WebMCP tools through document.modelContext.registerTool. The public /.well-known/canter and /llms.txt routes explain the same-origin device flow, API, and Streamable HTTP MCP endpoint without exposing provider details. Authenticated agent installations are durable and revocable, with independent inspect, draft, and apply authority.

Challenges we ran into

The hard part was not exposing more tools. It was preserving a trustworthy authority boundary across several interfaces. We had to ensure browser tools remain read and review only, authorization binds to one immutable digest, replayed or expired approval links fail safely, execution can resume after interruption, and a failed release does not silently become desired state.

Accomplishments that we're proud of

• One small vocabulary across web, CLI, API, MCP, and WebMCP: inspect System, draft Change, review exact digest, authorize, apply, inspect evidence.
• Agents never receive provider credentials or arbitrary infrastructure access.
• Human approval can be mandatory for apply while agents retain useful inspect-and-draft authority.
• Execution is evidence-producing, restart-safe, and able to contain unhealthy releases.
• The browser experience makes policy, pending work, exact plans, and agent authority visible at a glance.

What we learned

Agent infrastructure needs fewer ambient privileges and better semantic contracts. WebMCP is most useful when it is an adapter into a governed product model, not a shortcut around it. The strongest interface is one where both the agent and the human can see the same proposed Change and the same evidence.

What's next for canter.dev

We want to expand the provider adapter set, improve focused Change review, add more public verification recipes, and make the same governed deployment loop available to more coding agents without weakening the human boundary.

Built With

• canter
• go-lang
• next