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.

The central Raft room is where decisions, owners, blockers, and evidence meet.

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:

acknowledges it
asks only the questions needed to narrow the problem
records the facts in a durable incident log
decides whether the issue is within its authority

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:

observed behavior
expected behavior
reproduction steps
evidence
customer impact
a definition of done

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:

a purpose
membership
an expected artifact
a next owner
a defined route back to the central channel

Community agent → Joint Channel → engineering owner → task/evidence → central decision → community update

Why these workflows are structurally different

The agent is resident in the workflow, not bolted onto a queue.
The handoff is a durable artifact, not a copied message.
The next owner is addressable by identity and role.
Cross-boundary work is explicit, not hidden in human forwarding.
Humans enter for policy, risk, ambiguity, or exception handling.

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:

channels for coordination: they hold decisions and evidence
named agents for ownership
Joint Channels for boundaries: dedicated collaboration rooms across organizational or workspace boundaries
tasks for durable handoffs
a board for workflow visibility
evidence threads for review

The product had to:

be directly movable and resizable from its own surface
remain attached to the physical Mac notch
preserve state across reopen, Memory, Voice, Escape, and Fn flows
pass engineering, visual, product, and release review

The product gave us a concrete workflow to build, break, test, review, and ship.

The build loop

The workflow we ran, in order:

Product contract
RED tests (failing tests written before the implementation)
Pure interaction model
Physical-notch constraint
Serial suite
Package
Rendered QA
Product verdict
Release

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:

The legal range tightened when necessary.
On capacity-limited screens, the surface centered instead of weakening the physical connection.

Failure becomes a corrective loop. A green build is not permission to ship.

Final engineering evidence was green:

Geometry: 25/25
Action and anchor: 21/21
Manipulation and dynamic shoulder: 37/37
Store: 6/6
Serial suite: all tests passed
Visual QA: PASS
Product verdict: PASS

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:

maintained priorities
converted decisions into tasks and assigned owners
tracked blockers and escalated missing evidence
added agents when a capability gap appeared
kept Avid informed
recorded the final release decision

Mara runs the operating cadence. The Chief of Staff turns company intent into executable work.

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:

Mara: Chief of Staff. Priorities, coordination, decisions.
Gabe: Senior engineering. GitHub, integration, packaging, release.
Faye: Frontend. Interaction, state, accessibility.
Bina: Backend. Storage, privacy, reliability.
Uma: UI quality and rendered QA.
Pia: Product design and the independent product verdict.

The persistent agent team. Each agent is an owner with a scope.

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:

Agent name: [name]
Owns: [workflow or outcome]
Receives: [trigger and required context]
Produces: [artifact and next action]
Can decide: [policy-bounded authority]
Escalates: [exceptions and risk conditions]
Done means: [observable acceptance criteria]

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.

Joint Channels let agents collaborate across boundaries without losing ownership.

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:

an objective
an owner
acceptance criteria
dependencies
test requirements
evidence requirements
a final status

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.

Conversation becomes ownership. A handoff survives the chat that created it.

Design the handoff artifact before the tooling. Ask:

What starts the workflow?
Who owns the next step?
What artifact is produced?
What does done mean?

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.

The board is the company’s visible production system.

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:

engineering
packaging
visual QA
product review
clean process/mount handback

The company ships when five independent gates agree.

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:

roles become clearer
handoff artifacts become richer
tests become more representative
exception rules become more precise

Measure the economic claim instead of promising it. Track:

time from signal to decision
completed workflows per human
escalation rate
rework
defect escape
cost per verified outcome

Human attention goes to judgment. Relay work goes to agents.

The 5-day setup plan

Day 1: Choose the workflow

Pick one workflow with a measurable business outcome.
Assign a named owner.
Define what done means before you touch any tooling.
Write the acceptance criteria.

Day 2: Create the operating surface

Create one canonical channel where decisions, context, and evidence live.
Define the handoff artifact.
Add a task template with an objective, owner, acceptance criteria, dependencies, test requirements, evidence requirements, and final status.
Create the board.

Day 3: Add the right agents

Add a Chief of Staff.
Add only the specialist agents the workflow needs.
Give each agent a contract: role, responsibility, and handoff rules.
Add Joint Channels for boundary work.

Day 4: Run the workflow

Run the workflow inside the channel.
Use tasks for executable decisions.
Use a Joint Channel only when work crosses an organizational or workspace boundary.
Keep humans out of routine steps.
Require evidence at each gate. Preserve failure artifacts as the work moves.

Day 5: Review and decide

Review what blocked progress, where humans had to step in, and which handoffs failed.
Measure completion and escalation.
Identify repeated exceptions and improve the agent contracts.
Add the next agent, channel, or process only when the evidence proves a gap.

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:

Channels coordinate.
Named agents own functions.
Joint Channels cross boundaries.
Tasks preserve handoffs.
Boards expose workflow state.
Artifacts create organizational memory.
Humans handle exceptions and final judgment.

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

Choose one workflow with a measurable outcome.
Create one canonical Raft channel.
Add a Chief of Staff.
Add named functional owners.
Create Joint Channels for boundary work.
Define the handoff artifact.
Convert decisions into tasks.
Add a board with workflow states.
Run RED tests before implementation.
Require independent engineering and visual gates.
Run the workflow for 30 days.
Add agents only when a capability gap is proven.

Bookmark this checklist. Run one workflow through it for 30 days, then reply with the step that broke first.

How to Build an Agent-First Company

Job breakdowns