ARCS: how we let AI agents build, with checks

At Studio Northstar we build software with AI agents: our own products, and software for other businesses. An agent that carries out a task is fast. An agent that then approves its own work misses the mistakes it made itself. ARCS is the system we use to keep those two roles apart, and to fix in advance where a person has the final say.

What is ARCS?

ARCS is our own agentic platform. The name stands for Agentic Reasoning & Coordination Systems, and a single specialist system inside it is called an ARC. ARCS splits work into bounded tasks and assigns them to specialist groups of agents, which we call councils. Their specialisms include strategy, code, security, production readiness and search visibility. Every task is anchored to the long-term goal: the north star.

Technically, ARCS is a private MCP server with a CLI. Agents use it to run against a local codebase, with persistent checkpoints, runs that can be resumed and explicit handoffs from one ARC to the next. We use it for all of our products and on client engagements. The product page is at ARCS.

In Building effective agents⁠↗, Anthropic separates workflows, where models and tools follow predefined code paths, from agents, which decide their own steps and tool use. ARCS sits in between. Inside a task, an agent picks its own steps. The route around it is fixed in the rules of the system: who gets which task, when the work is checked and when it stops. That makes ARCS a form of multi agent orchestration, an agentic workflow with agents inside it.

Why councils instead of one agent?

Because one agent that does everything also judges everything itself. An AI model checking its own work can overlook its own mistakes. On large jobs it can lose sight of the original goal and still report the task as done. The final output does not always show it.

Research on models as judges points to the same risk. In Judging LLM-as-a-Judge⁠↗ (2023), Zheng et al. describe, among other things, a self-enhancement bias: a model acting as judge may rate its own answers more favourably. The same paper reports that strong models agree with human judges in over 80 percent of cases, about as often as humans agree with each other. So a model makes a useful reviewer, as long as it is not reviewing its own work.

A council is a group of agents with one specialism. Splitting the work gives each task the agent with the right knowledge and tools, and guarantees that someone else looks at the result. The pattern itself is known. Anthropic calls it orchestrator-workers: a central model breaks down tasks, hands them out and combines the results. What ARCS adds is the checks and limits around that multi agent system.

More agents is not automatically better. Anthropic advises starting with the simplest solution and adding complexity only when it clearly helps. ARCS follows the same rule: a task does not get a heavier route just because an ARC exists for it. A small, bounded task gets one pass with a fixed check. Only work with many dependencies, real uncertainty or real consequences gets a full loop.

How does a task move through ARCS?

In six steps, the same ones described in the method on our homepage.

1. A brief comes in. Before anything is built, we write down the goal and what counts as done.
2. The work is split up. Into bounded tasks. Each one goes to the council with the right specialism.
3. Nobody marks their own work. One model does the work, an independent reviewer checks it and a third check covers the fix.
4. Every run has limits. A run stops on a named reason and leaves a checkpoint that can be inspected and resumed.
5. People decide at the gates. The system brings the work to a point where a person says yes, no or change this.
6. Sensitive work stays in-house. When material can't go to an external AI provider, it runs on Northstar One, our own machines and models.

Inside a task runs a quality loop: a candidate, a fixed check, a targeted repair and another check. By default that is at most three attempts. If the same failure comes back, it counts as no progress and the loop stops, so an agent never keeps circling the same problem.

A deterministic planner decides who gets a task. When explicitly switched on, a small decision model runs alongside in shadow mode: it makes its own pick, but that pick never changes the routing. How that works is covered in five decision points for Jev.

Across a whole project, these steps fall into four stages: research, strategy and data, build and operate.

Why does no model review its own work?

Because a reviewer that made the work brings the same assumptions and blind spots with it. In ARCS the reviewer is therefore independent: a different model, or a separate context that did not make the work itself.

An agent that builds first and then calls itself the reviewer is still the builder. The working instruction is strict about it: the independent reviewer may not be the same context that wrote the change, unless a separate reviewer demonstrably ran.

We are just as strict about what we claim. If an environment cannot prove that a different model actually ran, ARCS records it as planned, not as done. The technical documentation calls this “no fake model switching”. The same goes for tests, browser checks and tool calls: whatever we claim must actually have run.

Building our app Plens put that principle into practice. On 24 September, Claude Code ran an independent review of the app with separate read-only agents: one for external connections, one for the web repository and one for code and UX. The first blocking finding was that the entire app lived in a single 317-line file, with no deep links. More on that kind of review in AI code review by a council.

When does a run stop?

Always on a named reason. A run in ARCS is bounded and stops as soon as one of six situations occurs.

At every stop, ARCS stores a checkpoint containing, among other things, the objective, the state of the loop and the arguments needed to continue. You can see where the work stopped, and the run can later pick up exactly there.

What an agent may do is not written in the task text. “Prompt text is never execution authority”, the ARCS documentation says. Permissions come from a recorded policy with allowlists and explicit grants. An agent that reads in a document that it is allowed to do something does not gain that permission by reading it. ARCS also never deploys anything to the cloud by itself.

Where does a person decide?

At agreed points. There, a person approves the work, rejects it or asks for changes.

We agree on those points in advance, and a few are always fixed. Money, contracts and commitments to customers require a visible final action by a person. Writes to external systems, database migrations and writes to GitHub need explicit approval. And the quality loop may never skip a human gate or widen what a tool is allowed to do.

Heavy routes need approval too. ARCS has two Super ARCs, one of them with 72 controls for finishing an AI product. They only start after explicit approval.

This is what is usually called human in the loop AI. In ARCS, the agents bring the work to the decision point with the completed checks attached. The person then judges a result with evidence, without having to watch every intermediate step.

Can you use ARCS yourself?

Not yet. There is no version you can run on your own; we use ARCS inside client engagements.

Today the interface is a CLI and MCP. We are building an operator console where a run can be watched, paused and resumed without typing commands in a terminal. After that, we want to make ARCS available through MCP and a GitHub App with private access. A SaaS version is planned but not built.

What you can do now is have ARCS put to work on your own project, from a new product to a review of existing code. For the wider picture of agentic engineering, read what is agentic engineering.

Curious what ARCS could do for your project? Get in touch. We start with what you want to achieve.