ABT's 5th Revision: What It Takes to Build an Autonomous Company

by Jared Little AI Learning
ABT's 5th Revision: What It Takes to Build an Autonomous Company

ABT’s 5th Revision: What It Takes to Build an Autonomous Company

We’ve rebuilt the operating model for Alien Brain Trust five times.

Not because the first four failed — because each one revealed the next problem to solve. We’re now on revision five, and for the first time, it feels like infrastructure rather than experimentation.

Here’s what changed across each revision and what we learned from each one.

Revision 1: The Manual Phase

The first version of ABT had no AI agents. Just a founder with Claude in a browser tab, writing prompts by hand, copying outputs into documents, managing everything manually.

It worked. Sort of. The output quality was high when we paid attention. The throughput was low. Everything depended on Jared being at the keyboard.

What we learned: AI without automation is just a better calculator. The real leverage is in removing the human from the loop for repeatable work.

Revision 2: Prompt Templates and Slash Commands

The second iteration systematized the prompts. We built a library of reusable templates for content generation, code review, and research. We added Claude Code slash commands for the most common tasks — /blog-post, /commit, /sp-scan.

Output quality became more consistent. Tasks that used to require careful prompt crafting became one-command operations.

What we learned: Templates solve the inconsistency problem but not the throughput problem. You still have to invoke everything manually. The work becomes more predictable, but it doesn’t scale.

Revision 3: Agent Personas and Role Definitions

The third iteration introduced the concept of agents with persistent identities. Not just “Claude doing a task” but a CEO agent, a CTO agent, a content writer with a consistent voice and a defined scope.

We wrote SOUL.md files for each role — who they are, what they value, how they communicate. TOOLS.md files defined what each agent could and couldn’t touch. CONTEXT.md files gave them the strategic background.

Content got more consistent. The agents started feeling like collaborators rather than tools.

What we learned: Persona definition is necessary but not sufficient. An agent with a great identity and no memory of previous work is still starting from scratch every session. The missing piece was persistent operational state.

Revision 4: Paperclip AI (The First Attempt)

The fourth revision introduced Paperclip AI — a self-hosted agent orchestration platform that gives agents persistent state, project tracking, and the ability to run tasks asynchronously.

This was the version that took 16 hours to set up and then lost all its state overnight due to a Docker named volume mapping issue.

It was also the most valuable failure we’ve had.

What we learned: Persistent infrastructure requires persistent discipline. You can’t treat a stateful system like a stateless one. Named volumes, no backups, and configuration that only existed on a running server is a liability, not an asset. Everything that has operational value has to be in version control.

Revision 5: Infrastructure as Code, All the Way Down

The current version is what revision four should have been from the start.

Every piece of the operating model is committed to the repo:

  • Agent personas and system prompts (02-Infrastructure/agents/)
  • Corporate strategy and 90-day plan (00-Corporate/)
  • Infrastructure configuration (Terraform)
  • Docker compose configuration (version controlled, synced to S3)
  • Deployment runbook (committed to the instance during bootstrap)
  • Backup scripts (three-layer: bind mounts + EBS snapshots + nightly pg_dump)

The agents themselves run continuously on a $19/month AWS EC2 instance. The CEO agent has corporate context. The CTO agent has the codebase. The content writer has the brand voice and content pillars. Each one has a cloned copy of the repo as their working directory.

When revision 5 had a database failure — which it did, on day two — the rebuild took under 2 hours. Everything the agents needed to resume work was already in the repo.

What “Autonomous” Actually Means at This Stage

We want to be honest about what “autonomous company” means at revision five.

The agents run tasks. They write code, create content drafts, build infrastructure. But a human — Jared — reviews every PR before it merges. Every blog post goes through an approval step. Infrastructure changes require explicit authorization.

Full autonomy isn’t the goal at this stage. Reliable, auditable, reviewable autonomy is.

The agents generate work at a pace no single person could match. The human reviews, approves, course-corrects. The agents don’t make irreversible changes without a checkpoint.

That’s the right architecture for where we are: a small company that can’t afford a mistake to ship unreviewed, but also can’t afford to bottleneck everything on one person’s bandwidth.

The Next Problem to Solve

Every revision has exposed the next constraint. Revision five exposed two:

Agent workspace isolation. When five agents share the same repo, they can create merge conflicts if they’re all working on similar files simultaneously. The current workaround — separate clones per agent (/paperclip/workspace/ceo, /paperclip/workspace/cto, etc.) — works but requires manual coordination for PRs that touch the same files.

Agent awareness of each other. The CEO knows about the CTO because we told it. The CTO doesn’t know what the content writer is working on. Building genuine cross-agent context — so agents can coordinate without human intervention — is the next architectural problem.

Revision six is already taking shape.

Why We’re Building This in Public

The honest answer: because building in public is how we find the real problems.

Every post we write about what broke, what we rebuilt, what we learned produces inbound questions from people running into the same issues. Those questions sharpen our thinking, improve the documentation, and occasionally reveal a solution we hadn’t considered.

The goal for ABT isn’t a perfect AI company. It’s a reproducible playbook for what an AI-native small business actually looks like — five revisions, hard-won lessons, and everything committed to the repo.

Tags: #building-in-public#ai-agents#autonomous-business#paperclip-ai#lessons-learned

Comments

Loading comments...