How to Build an Agent-First Company
i wrote the A - Z Build of how to build an agent-first business
This is the complete build, in order, with a checkpoint after every piece.
Bookmark this before you forget
TLDR: If you don't wanna read 2,054 words then go here https://github.com/codejunkie99/LocalFlow
What does an Agent-First Business mean
Turn the AI off for a day. If your company gets slower, it is AI-enabled. If the work stops, it is AI-native.
Most companies that say they run on AI are AI-enabled. Turn the AI off and people keep working. Slower, but working.
The other kind looks like this.
At 2:07 AM, a customer reports a bug.
A resident agent acknowledges it, asks the follow-up questions, keeps the running record, and hands the problem to the agents that own the product.
Engineering investigates, tests, and ships a fix. The resident agent reports back.
That scene runs on five things: persistent roles, durable handoffs, explicit boundaries, visible work, and human review at defined gates.
We ran a small version of that company in Raft to test the model: one canonical channel, a Chief of Staff agent, five specialist agents, and a real macOS product.
The first artifact passed engineering and failed visual QA. The successor passed 89 of 89 engineering checks, visual QA, and the product verdict, then went out as the RecallFlow v0.2.0 internal preview.
This is the field guide: the operating components, the human exception layer, and the Raft setup that makes them practical.
Agents own normal workflows. People own judgment, policy, and exceptions.
Bookmark it before you forget. The setup takes five days.
AI-enabled versus AI-native
An AI-enabled company still has humans owning every workflow. AI drafts, summarizes, or recommends.
An AI-native company gives agents persistent ownership, identities, tools, artifacts, and escalation rules. Humans set policy and handle exceptions.
The unit is a team of agents that keep work moving together
Two workflows an AI-native business should support
Scenario one: the resident support agent
The resident agent lives in the customer's shared room.
It treats the whole conversation as one operational record instead of a series of tickets.
When an issue arrives, the resident agent:
If the issue is within its authority, the agent resolves it in the room. If it is not, the agent creates a structured handoff to the development agents.
That handoff includes:
The development agents start from that artifact. No one reconstructs the incident from a forwarded message.
The result is a closed loop. The development agents fix and test the issue, then post verified evidence back to the resident agent.
The resident agent tells the customer what shipped and whether follow-up is required.
Several specialized agents worked behind the scenes, but the customer experienced one continuous interaction.
Customer room → resident agent → incident artifact → development agents → test/release evidence → customer update
Scenario two: community feedback closes the loop
Botiverse is the company. Raft Community is the community surface.
In a conventional support model, a user reports a bug to a moderator, the moderator forwards it to support, support forwards it to engineering, and engineering eventually responds.
Every relay adds latency and loses context.
In the AI-native model, the community agent recognizes a runtime problem, attaches evidence, and addresses the Botiverse agents that own the code.
The community remains a separate boundary, but the handoff is immediate and addressable.
A Joint Channel is the controlled boundary for this work. It has:
Community agent → Joint Channel → engineering owner → task/evidence → central decision → community update
Why these workflows are structurally different
A real product makes the model concrete
To test these components, we used Raft as the workspace for a small product company around a real macOS product: a notch-native productivity app.
Raft is the shared operating workspace. It gave us:
The product had to:
The product gave us a concrete workflow to build, break, test, review, and ship.
The build loop
The workflow we ran, in order:
The first artifact passed engineering checks but failed visual QA.
At the legal left and right positions, the surface only overlapped the hardware notch by a narrow sliver. It did not look like one continuous notch-native surface.
The artifact was rejected. The successor introduced a dynamic shoulder rule:
Required shoulder = max(24 pt, 0.25 × measured notch width)
The rule had two effects:
Final engineering evidence was green:
Putting the components into practice
Raft was the workspace for the model. Here is the setup, component by component.
1. Create one canonical channel
Create one source-of-truth channel before you add complexity. We used #product-build.
Every decision, requirement, blocker, task link, test result, screenshot, and release decision entered there first.
Execution could move into a task, a direct message, or a Joint Channel, but the canonical decision returned to this room.
Setup rule: every important decision starts in the canonical channel.
2. Add a Chief of Staff
Mara was the operating layer. She:
The Chief of Staff keeps the company moving and prevents premature completion. The engineering agents write the code.
3. Build a named agent org chart
Once the components were clear, we instantiated them as a Raft team. Our functional owners:
Give each agent a name, scope, inputs, outputs, authority, escalation rules, and definition of done.
Otherwise the company has a chat list, not an org chart.
Copy this agent contract for each one:
4. Use Joint Channels at boundaries
Use Joint Channels when work crosses an organizational or workspace boundary: a customer and the company, a community and the product team, or a partner workspace and an internal team.
Internal cross-functional work can stay in a normal Raft channel.
The pattern:
Central channel → Joint Channel → specialist task → evidence → central decision
In the support scenario, the resident agent lives in the customer's room. It asks questions, keeps the log, and escalates only what it cannot solve.
In the community scenario, the community agent identifies a runtime problem and addresses the agents that own the code. No human relay chain starts.
5. Turn decisions into tasks
A message is temporary. A task is durable.
When a decision becomes executable, Raft turns it into a task with:
People can create tasks. Agents can also create them automatically as part of the workflow.
The handoff then lives in the task, with a record that outlasts the chat.
Design the handoff artifact before the tooling. Ask:
6. Use the board as the production system
Use a board with four states: Todo, In Progress, In Review, and Done.
The board lets humans see what the company is doing without reading every agent message.
Agents can also hand work to each other based on their roles, responsibilities, and the workflow stage.
Humans on the loop, not in every loop
Humans own strategy, policy, risk, budget, ambiguity, and the final release decision.
Agents own routine execution, coordination, testing, documentation, and policy-bounded decisions.
The goal is not no humans. The goal is no human relay for normal work.
Release is a company decision
Mara recorded the internal-preview release only after five independent gates agreed:
The final record was RecallFlow v0.2.0/9, on canonical head aa1bf9e7, with strict codesign and exact-hash evidence.
The standing caveat: external Gatekeeper distribution still requires Apple Developer enrollment and signing.
Why the model compounds
Bolt-on tools stay static because the surrounding workflow does not change.
An AI-native system improves its operating memory with every run:
Measure the economic claim instead of promising it. Track:
Human attention goes to judgment. Relay work goes to agents.
The 5-day setup plan
Day 1: Choose the workflow
Day 2: Create the operating surface
Day 3: Add the right agents
Day 4: Run the workflow
Day 5: Review and decide
After day 5, run the workflow daily.
Aim for one workflow that is executable, observable, and improvable. Grow the agent organization from there.
The reusable pattern
Raft becomes the operating system:
That is how to set up an AI-native business. Not by attaching an AI assistant to an existing company, but by designing the company so agents can carry ordinary work from trigger to outcome.
At 2:07 AM, the room does not need an all-hands. It needs a resident agent, a durable handoff, a named owner, a task, a test, a review, and a release decision.
Reproduction checklist
Bookmark this checklist. Run one workflow through it for 30 days, then reply with the step that broke first.