You Don’t Need a Backend for an Agent
Backends were invented for humans. Agents can run on artifacts and APIs.
From first principles, a backend exists to serve a client: store state, enforce rules, and expose interfaces for humans and systems. If your primary “user” is an agent operating inside a sandbox with repo access, you can postpone most of that complexity.
This is not anti-backend. It’s pro-sequence.
Why most backends exist
Traditional apps need backends because:
- humans need a UI that reads/writes state
- you need shared persistence across many sessions
- you need permissions and multi-tenant boundaries
- you need integrations and webhooks
Those are real needs. But they’re not Day 1 needs for every workflow.
What an agent needs instead
An agent needs:
- a place to store state (files)
- a way to execute work (sandbox)
- a way to call the world (APIs/connectors)
- a way to prove correctness (checks/artifacts)
The repository covers state and auditability. The sandbox covers execution. APIs cover “touching reality.”
That’s enough to run a surprising amount of a business.
The pattern: artifacts first, services later
Instead of building a backend to “manage” your business logic, you can start with:
- outreach templates in a file
- a pipeline file that the agent updates
- an experiment log
- scheduled tasks that generate daily plans and assets
Then, when you hit a real constraint, you add a service:
- You need better sending and tracking → email/SMS provider
- You need billing and receipts → payments
- You need shared real-time state across a team → database
External services become optional upgrades, not prerequisites.
What you gain
- Speed: you can ship operational capability without building product surface area
- Clarity: the business state is readable and versioned
- Safety: rollbacks exist because Git exists
- Leverage: agents can operate on the same state you review
What you give up (until you choose to add it back)
- real-time dashboards
- multi-user interactive UX
- long-lived servers
And that’s fine, because those are costs. The goal is to earn the right to pay those costs with demand.
The OutcomeDev stance
OutcomeDev doesn’t force you to overbuild. It forces you to be explicit:
- What is the outcome?
- What are the constraints?
- What artifacts should exist?
- What proof is required?
That’s the difference between “AI as vibes” and “AI as a business operator.”