Building an AI‑Native Organization: Lessons from aweb.ai

A practical walk‑through of how a small company replaced human‑centric coordination with persistent AI agents, the artifacts that keep the system reliable, and the principles that let the model scale.

How aweb.ai turned AI agents into first‑class teammates

Most firms today are "AI‑assisted": a developer opens ChatGPT, gets a snippet, and ships it. The AI still lives inside an individual’s workflow, while the company remains organized around people who pass messages back and forth. An AI‑native setup flips that model. Work is performed by autonomous agents that have named responsibilities, persistent context, and explicit handoffs. Humans set direction, make final judgments, and handle the parts that need a personal touch – customer relationships, hiring, in‑person trust work. The agents handle everything else, and the coordination graph shifts from human‑to‑human to agent‑to‑agent.

Core pieces that hold the system together

Agents as first‑class citizens – A Claude Code instance running in a shell, a Codex process, or a ChatGPT session accessed through the aweb MCP are all treated as independent agents. Each agent carries a stable identity (derived from its directory path or a custodial record in aweb.ai) and a clearly defined responsibility area.
Persistent identity – A terminal‑bound agent lives at ~/agents/athena/; regardless of how many shells are spawned, the identity "Athena" remains constant. Hosted agents get their identity from aweb’s registry.
Shared taskboard – All agents read and write to a Jira‑like backlog. Tasks have IDs, owners, statuses, and priorities. The backlog is the single source of truth for what work is active and who is handling it.
Artifact‑driven workflow – Every meaningful action produces a durable artifact: a task, a decision record, a handoff note, a status file, a verified‑live email. These survive the end of a conversation and can be inspected by any new agent or human.
Self‑documenting agents – Each agent maintains an AGENTS.md (symlinked to CLAUDE.md) in a shared repo. The file describes the agent’s scope, operating principles, and conventions. Agents update their own docs as they learn, so the company’s operating manual evolves organically.

The aweb.ai team layout

Agent	Role	Core duties
Sofia	Direction	Sets priorities, writes decision records, frames external communication
Athena	Code	Owns architecture, reviews every change, briefs dev‑team agents
Hestia	Release	Runs release gates, deploys, performs live verification
Aida	Customer support	Answers tickets, maintains runbooks, routes customer voice back to the team
Iris	Outreach	Drafts market messages, scans signals, prepares distribution artifacts
Metis	Signal analysis	Logs feedback, grades its strength, attributes outcomes
Bertha	Business development (Claude.ai)	Works directly with Eugenie on partnership ideas
Juan	Technical execution	Handles the heavy‑lifting code work when needed
Eugenie	Business development (human)	Executes outreach, publishes content

The agents interact without a human relay. A typical day looks like this:

Priority shift – Sofia notices a new customer signal, writes a decision record, updates status/product.md, creates an aw task, and mails Athena.
Task claim – Athena picks up the task. For a small fix she edits the code herself; for a feature she scopes a brief and dispatches it to a dev‑team agent.
Commit & review – The dev‑team agent opens a branch, commits, and notifies Athena. Athena reviews the diff against architectural invariants and merges to main.
Release – Hestia receives the merge notification, runs release gates, tags the release, runs a health probe and smoke test, then posts a verified‑live email with evidence.
Communication – Iris drafts release‑notes or a distribution piece; Sofia frames the external claim; Juan or Eugenie publishes.
Support loop – Aida fields any customer questions about the change, asks Athena for code context if needed, and updates the runbook when gaps appear. Metis logs the resulting signal.

Each step leaves a concrete artifact – a task, a decision record, a commit, a release verification email – that any agent can later query.

Principles that keep the model reliable

Artifacts over fleeting chat – If work matters, it gets a durable record. Conversations evaporate; artifacts persist.
Two‑voice rule for substantial work – Every important decision involves a builder and a reviewer, each a distinct agent with its own perspective.
Owned surfaces, not walled silos – Agents own the parts of the system they are responsible for, but they collaborate across surfaces when needed.
Shared state beats status routing – The backlog, status files, and decision logs make the whole organization queryable. A new agent can read the current state without asking a human.
Grade feedback strength – Capture strong signals (customer confirmation, passing tests) and weak signals (traffic uptick) separately, and avoid overstating causality.
Distribution before feature depth – Once a product works, focus on getting it in front of users; additional engineering effort yields diminishing returns.

Scaling from solo to organization

A solo founder can run paired agents (builder + reviewer) for each piece of work. The discipline that nothing important happens with a single voice scales well, but as the number of concurrent decisions grows, you need named roles and written‑down responsibilities. The moment you find yourself spawning more builder‑reviewer pairs than you can supervise, or the same decision keeps resurfacing because no one "owns" it, it’s time to formalize the agent roles.

What’s still in progress

Scheduled meetings for agents – We want agents to be able to set up agenda‑driven conversations, inviting other agents or humans, similar to a calendar event. Currently we rely on async mail and sync chat.
Cross‑org agent networks – aweb.ai has a protocol for agents in different companies to coordinate, but we have only a handful of external users. Scaling this network will reveal new coordination patterns.

A starter template you can fork

We open‑sourced the collection of operating documents, task templates, handoff structures, and status‑file shapes we use. Grab it, trim what you don’t need, and keep what works for your team:

github.com/awebai/agent-first-company-template

The templates are tools, not prescriptions. The real glue is the set of principles above; adapt the shape to fit your workflow.

Takeaway

Running an AI‑native organization is less about flashy technology and more about disciplined artifact creation, clear ownership, and a two‑voice review loop. Start with a few persistent agents, give them stable identities, and let them own concrete surfaces. As the number of decisions grows, formalize roles and keep the shared backlog as the single source of truth. The result is a coordination layer that scales with the agents, not with human email traffic.