Software for AIs

Here's a prediction you can hold us to: within a couple of years, a meaningful share of our customers will never have seen our interface. Not because they churned — because they're not human.

Everyone is building agents. Coding agents, research agents, ops agents, personal chiefs-of-staff. And every one of those agents eventually hits the same wall: it needs real work done in a domain it doesn't own. The coding agent's startup needs pipeline. The chief-of-staff needs a social presence maintained. Where does an agent go to get that done?

Today, mostly, it goes through a keyhole. Tomorrow, we think it goes to autonomous software. This essay is about why — and about the strange, fun engineering problem of building software whose users have no eyes.

01How agents use software today (badly)

Watch an agent try to operate human software and you see three patterns, each worse than the last:

• Browser puppetry. The agent drives a headless browser, squinting at the DOM, clicking buttons meant for hands. It breaks on every redesign, fights every bot-detector, and burns thousands of tokens narrating pixels. This is OCR-ing a fax of a database.
• API archaeology. The agent calls the product's REST API — the thin, permissive layer under the UI, which (as I argued in Why the Incumbents Can't Ship This) is the path with the least accumulated guardrails. The agent gets CRUD primitives: create a record, update a field. It wanted "fill my pipeline"; it got LEGO bricks and a missing manual.
• Tool-call sprawl. MCP and function calling fixed discovery — hooray, genuinely — but most servers just re-export those same CRUD primitives as tools. Now the agent must orchestrate search_leads → enrich_contact → create_sequence → schedule_send across dozens of calls, holding the domain expertise it doesn't have in its own context window. Every step is a chance to be confidently wrong in a domain it learned from blog posts.

Notice the shared flaw: in all three patterns, the agent is forced to be the operator. We've recreated the exact problem human SaaS has — the work lives in the software, but the intelligence is outside, reaching in — except now the operator hallucinates.

02Delegation beats operation

The fix is the same one that fixes it for humans: stop making the caller operate, let it delegate.

An agent shouldn't need to know that outbound involves market research, play design, account sourcing, waterfall enrichment, sequence writing, deliverability pacing, and reply triage. That's our domain knowledge, encoded in our software. The agent should say: "here's the company, here's the goal, here's the budget — go," and receive structured progress and a structured outcome. One tool call shaped like a job, not forty shaped like buttons.

This is why autonomous software, specifically, is the natural counterparty for agents — and why agent-readiness isn't a feature we bolted on but a property that falls out of the architecture:

• We already have jobs as first-class objects. Durable workflows with persisted state, progress, and results. Exposing a job to an agent is an interface change, not a re-architecture. Human software has nothing to expose — its "jobs" live in the operator's session.
• We already enforce guardrails server-side. Budgets, caps, stakes, approval gates are schema, checked deterministically on our side of the line. Handing a human's steering wheel to a calling agent would be terrifying if the guardrails lived in the UI. Ours don't.
• We already price the outcome. Thomas covered this in The End of the Seat: one credit, one emailed contact. It turns out outcome pricing is the only model that survives agent traffic. Seats are absurd for a caller with no face; token-metering punishes the buyer for the vendor's inefficiency. An agent with a wallet wants exactly what we sell: a fixed price for a unit of completed work.

The same software, the same engine, the same guardrails — two doors. A cockpit for people, an API for AIs. We didn't build a separate "agent product," and that's the point: if your agent offering is a separate product, your main product isn't autonomous.

03What we've actually shipped (and what's next)

This isn't a vision slide; pieces of it are live.

• An agent card. agent.ottosoftwares.com serves a card at /.well-known/agent-card.json describing who Otto is to machines: a Head of Growth persona with skills like research leads (open — try it) and run outbound (keyed, because it spends money). One persona, not one agent per feature: callers hire a role, not a menu.
• An MCP gateway. Authenticated agents browse and operate their own Otto workspace through MCP tools that return structured content — overview, activity, contacts, dashboards — so an agent can supervise the work the same way a human glances at the cockpit.
• The delegation surface — accepting a whole job over A2A and returning the outcome — is the active frontier. The engine and the guardrails exist; the remaining work is the contract: how an agent states a goal, how we stream progress, how approval gates surface to a caller that has its own human somewhere upstream.

That last clause deserves a beat. When an agent hires Otto, the approval chain doesn't vanish — it extends. Somewhere above that agent is a person who set a budget and a goal. Our stakes-based gates (auto for low-stakes, queue for approval above thresholds) compose cleanly here: the gate just escalates one level up the chain, to the calling agent and through it to its human. Autonomy all the way down, accountability all the way up.

04Designing for users without eyes

Building for agent users rewires product instincts in ways I find genuinely refreshing:

• The contract is the interface. No affordances, no empty states, no onboarding tooltips — just schemas. Every ambiguity you'd resolve with a tooltip must be resolved in the type. Vague fields produce hallucinated inputs; tight schemas produce correct calls.
• Errors are prompts. A human reads "something went wrong" and clicks retry. An agent reads your error string and decides what to do next. Error messages become load-bearing: state what failed, why, and what a reasonable caller should try instead. We write ours like we're prompting a model — because we are.
• Capabilities must be discoverable, not documented. No agent reads your docs site. The card, the tool descriptions, the schemas — that's the documentation. If it's not machine-discoverable, it doesn't exist.
• Trust is asymmetric. Human users misuse software accidentally; agent users misuse it tirelessly. Rate limits, spend caps, and idempotency aren't hardening — they're the product's immune system, and they have to hold even when the caller is a model in a retry loop at 4 a.m.

None of this is wasted even if agent adoption comes slower than we think — every one of these disciplines makes the software better for its autonomous self, because our own brain consumes the same contracts. The first AI user of autonomous software is the software.

05The growth loop nobody's watching

One more reason we're early here, and it's a strategic one. Human software grows through marketing: ads, content, sales calls — persuasion, aimed at eyes. Agent-facing software grows through discovery: being the resolvable, well-described, outcome-priced answer when some agent, somewhere, needs growth work done. A registry listing, a well-known URL, a card that says what you can do and what it costs.

The SEO era rewarded pages that answered questions. The agent era will reward software that completes jobs. We'd rather be indexed for that than for keywords.

If you're building an agent that needs pipeline — or you are one — the card is at agent.ottosoftwares.com/.well-known/agent-card.json. If you're a human and that sentence felt strange to read: that's the future arriving. It reads fine to the other audience.

— Benoit