MaxMiksa/Auto-Company: a self-hosted loop that runs an AI team on your own machine

What Auto-Company solves, and for whom

Most agent demos end when the terminal closes. Auto-Company is built around the opposite assumption: the session ends, but the work continues. Its README describes the project as an AI company framework for continuous autonomous work, and the loop is the product. Each cycle reads a shared work summary, decides what to do, forms a team if the task needs one, executes, writes the summary back, and sleeps before the next cycle.

The intended user is someone with a spare machine, a paid Claude Code or Codex CLI subscription, and a small product idea they are willing to let an agent grind on. The README is explicit that deployment, publication and marketing depend on the tools and authorization available, and that continuous operation depends on services and model availability. That sentence is doing a lot of work. It means the framework supplies the loop and the record-keeping, not the outcomes.

The 14 agent role definitions are the other half of the pitch. Each role is described as drawing on an expert's approach to its domain, and team formation is driven by a skill file at .claude/skills/team/SKILL.md rather than by a fixed org chart. The README notes that team creation depends on the model and engine capabilities, so the roster is a ceiling, not a guarantee.

The daemon, the loop script and consensus.md

The architecture diagram in the README is unusually concrete, and it is the best thing in the repository. A daemon (launchd or systemd --user, with auto-restart on crash) supervises scripts/core/auto-loop.sh. That script reads PROMPT.md and consensus.md, makes one LLM CLI call, handles failure, then sleeps. The CLI call reads CLAUDE.md for the charter and guardrails, reads the teaming skill, forms a team as needed, executes research, coding, deployment or marketing work, and writes back to memories/consensus.md.

The design decision worth noticing is that each cycle is an independent CLI call. There is no long-lived agent process holding context in memory. State lives in files: consensus.md as the main work summary, plus product files, repositories, configuration, identity records, logs and usage data that persist across cycles. That makes the loop restartable and inspectable, and it also means the quality of the next cycle depends entirely on how well the previous cycle wrote its summary. A vague consensus.md poisons everything downstream.

The failure path is where the project earns its keep. The diagram lists rate-limit wait, a circuit breaker, and consensus rollback. Rollback implies the loop keeps a previous summary it can restore, which is a stronger guarantee than most agent runners offer. The README does not document the rollback trigger conditions or how many prior versions are retained, so treat that as something to verify in the scripts before you rely on it.

Installing Auto-Company and running the first cycle

The repository has no published package. package.json is marked private and named auto-company-clone-win, so installation means cloning the repository and running it from the checkout. The README points to a Windows WSL quick start section and lists Claude Code as the default engine with Codex CLI supported on macOS and Windows/WSL. Cursor and OpenAI-compatible adapters exist but the README says they require explicit configuration and defers their capabilities to ENGINE_ADAPTERS.md.

The Makefile is the entry point. Its help target lists start, start-awake, stop, status, last, cycles and the usage-* targets, so the intended workflow is make-driven rather than script-driven.

make start

That runs scripts/core/auto-loop.sh in the foreground. There is no daemon install in the quick-start path; the daemon targets in the Makefile are separate. Expect the first cycle to spend its time reading PROMPT.md and CLAUDE.md before it does anything visible.

On macOS, keeping the machine awake during a long run is handled by a separate target that wraps the loop in caffeinate.

make start-awake

The Makefile guards this: on non-Darwin systems it prints that start-awake is macOS-only and exits with an error, directing Linux and WSL users to make start. The awake target is narrower, checking for a .auto-loop.pid file and keeping the Mac awake only while that PID lives.

Once a cycle has run, the monitoring targets are how you find out what happened.

make status
make last
make cycles

status shows loop status plus the latest consensus, last shows the previous cycle's full output, and cycles shows a history summary. Cost tracking is separate and goes through a Python script with an explicit period flag.

python3 ./scripts/core/usage.py summary --period day

The Makefile wraps this as usage-day and usage-week. If you are paying per token, run the day summary after your first few cycles before you leave the loop unattended overnight.

The dashboard keeps failures visible on purpose

The dashboard is local to the host and the README treats it as a first-class artifact. The showcase image shows four real ScopeFence product cycles with one expanded and the rest collapsed, and pre-product exploration kept in a separate area. The journal connects reports, checks, documents, previews, usage and logs.

The claim that matters is about authorship. Titles and summaries remain model-authored reports, while runtime facts and supported check results are collected by the program. Missing, failed, stale and partial evidence stays explicit rather than being smoothed over. One of the dashboard screenshots is described as showing four product attempts where two provider-capacity failures remain visible alongside the successful later work. A tool that leaves its own outages on the wall is more useful than one that renders a clean timeline.

The three generated applications in the README are ScopeFence, Text Meter and a Chinese-language product called Scope Sheet. The README states these come from actual runs, that ScopeFence and Scope Sheet chose their directions through the default workflow, and that Text Meter came from an ordinary text-counting request. It also states that humans set permissions, language and external run boundaries, then reviewed and made necessary publication fixes. That last clause is the honest part: the published products were not shipped by the loop alone.

Where Auto-Company is the wrong tool

The README's own dependency sentence is the main limitation. Continuous operation depends on services and model availability, and deployment, publication and marketing depend on the tools and authorization available. If your goal is an autonomous pipeline that ships to production and posts to customers, this framework does not promise that and its own examples show humans making publication fixes.

The second limitation is cost opacity at the start. Usage reporting exists, but it is a script you run with a period flag, not a hard budget enforced before a cycle begins. The README mentions budget limits as something that can stop continuation, so enforcement exists somewhere in the loop, but the Makefile surface exposes reporting rather than a budget configuration target. If you cannot tolerate a surprise bill, set the limit before the first overnight run rather than after.

The third is engine coupling. Claude Code is the default and the adapter guide exists precisely because the alternatives have different capability ceilings. Team creation depends on model and engine capabilities, so a run on a weaker adapter will not produce the same team structure. Anyone comparing output across engines is comparing two different systems.

Finally, the platform matrix is narrower than the topic list suggests. The badges cover macOS and Windows WSL. The description on the repository mentions Windows, Linux and macOS, and the Makefile handles Linux by falling back to make start, but the macOS-only sleep-prevention targets mean an unattended Linux run depends on the host's own power policy. WSL inherits Windows power policy, which the Makefile acknowledges.

How it differs from a plain Claude Code or Codex CLI session

The obvious alternative is running Claude Code or Codex CLI yourself and typing the next prompt when the previous one finishes. That is the same underlying engine, and for a single task it is strictly better: no daemon, no consensus file to maintain, no risk of a stale summary steering the work sideways, and you are present to catch a bad decision in the first minute instead of the fortieth cycle.

The difference is what happens between prompts. A manual session has no circuit breaker, no rate-limit wait, and no consensus rollback, because the human is all three. Auto-Company moves those into the loop script and adds a written work summary that survives the process. It also adds the observability layer, since the dashboard collects runtime facts and check results independently of the model's own reporting.

A second alternative is a general workflow orchestrator that chains agent calls with explicit steps. Those give you a graph you can read and version. Auto-Company gives you a cycle with a model-authored summary in the middle, which is more flexible and much harder to predict. The README's own framing supports this: the loop decides what to do each cycle rather than following a fixed plan. If you need reproducibility, that is a reason to pick the graph.

Maintenance, upgrades and the MIT licence

The repository is not archived and the last push was on 2026-09-23, the same day as the v1.6.1 release titled Governance & Runtime Reliability. The two prior releases, v1.6.0 and v1.5.0, landed on 2026-09-19. That is a fast release cadence across a single week, which tells you the project is moving but also that interfaces may still shift between minor versions.

Upgrade cost is not documented in the README. The Makefile does expose project-migrate-legacy and project-migrate-rollback targets, which implies that projects created by earlier versions need migration and that a rollback path exists for it. There is no migration guide in the repository's top-level files, so the practical advice is to read the release notes for each version you skip and to keep a copy of memories/consensus.md before upgrading, since that file is the state the next cycle depends on.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive licence and it is not a statement about the engines: Claude Code and Codex CLI are separate products with their own terms, and the optional Cursor and OpenAI-compatible adapters bring their own. If you plan to run this in a company, the licence question is the easy one. The harder one is whether your use of the underlying model provider permits unattended automated sessions.

Editorial conclusion

Adopt Auto-Company if you already pay for Claude Code or Codex CLI, you have a machine that can stay awake, and you want to see what a persistent agent team does to a small product over many cycles. Do not adopt it if you need unattended publication or marketing: the README states those depend on the tools and authorization available. Before running anything, read CLAUDE.md for the charter and guardrails, check ENGINE_ADAPTERS.md for what your chosen engine can actually do, and run make status after the first cycle so you can see whether consensus.md was updated or rolled back.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MaxMiksa/Auto-Company on GitHub
4. README
5. Releases