The missing project layer.

The basic unit of AI-assisted development has been a conversation: describe a task, inspect the result, correct the agent, repeat. As agents improved, the industry multiplied that unit. Developers now run several chats, terminals, worktrees or cloud sessions in parallel.

That adds throughput, but it doesn’t add up to a coherent project. Each session has a partial view. The developer remains responsible for remembering which agent knows what, which branch holds which decision, which review applies to which revision, and which apparent completion was actually tested.

The result is a curious kind of automation. Machines do more of the work, while the human spends more of the day supervising queues, carrying context and reconnecting processes the software treats as unrelated.

The central question is no longer “can an agent write the code?” It is “can the project keep its intent and move the work to a trustworthy result, without a developer conducting every transition by hand?” Charrette treats this as one problem with two halves: memory and ownership, and attention and orchestration.

Changing a mature system takes more than the repository. It takes the current goal, architectural intent, business constraints, approaches that already failed, temporary exceptions, local conventions, deployment risk, acceptance criteria, and the reasons one trade-off beat another.

Today that knowledge is spread across instruction files (READMEs, AGENTS.md, provider-specific rules), issues and pull requests, individual agent conversations and their compacted summaries, and the heads of developers who know which written rules are still current. The evidence, meaning diffs, test runs, logs and incidents, is rarely connected to the decisions it supports.

Documentation helps, but it flattens different kinds of knowledge. A Markdown file can hold text. It usually can’t say whether a statement is a settled policy, a hypothesis, a decision that applies to one service, an observation from a failed run, or a convention that went stale in February. Current practice puts all five into similar files and asks the next agent to guess their authority.

Standing is not activation

Agent products increasingly organise memory by when text enters the model’s context: always-on rules, instructions scoped to certain files, and skills loaded on demand when their description seems relevant. It’s a sound engineering answer to a real constraint, because context windows are finite and long instructions dilute attention. In 2026 some products went further and merged their separate knowledge stores into on-demand skills, because the two already loaded the same way.

But that merges two separate questions. Is this claim true? is a question about the project. When should an agent see it? is a question about delivery. A procedure for running a migration and the fact that a payment provider’s webhooks arrive out of order both load on demand, but only one of them can go stale, be contradicted or be superseded. Charrette keeps the two axes separate.

The context problem is being solved, mostly inside products

Cursor, GitHub, Devin and the labs’ own agents all now offer coherent project surfaces, cloud agents, repository-aware work and durable artifacts. That’s strong evidence the need is real. It also creates a structural risk: if a project’s memory, task history and coordination rules live inside one commercial environment, the team’s accumulated operating knowledge becomes part of that vendor’s moat. Changing the model is easy. Changing the system that remembers how the team builds is not. Charrette therefore treats provider independence as an architectural requirement, not a model picker.

Take a routine task. It should be triaged into acceptance criteria. An implementation agent makes the change. If the change touches a sensitive path, it needs a security audit. A reviewer from another lab should inspect the diff; if review finds a defect, an executor should repair it, and the repair should be reviewed again. A user-facing change should be tested against the original criteria. None of this requires a developer to copy a summary from one window to another, yet that is how it’s done, and a step the developer forgets simply doesn’t happen.

The developer is needed at the start, at the end, and at moments of ambiguity, risk or real trade-off. In between, they act as message bus and scheduler. This destroys real parallelism. Several agents can run at once, but each one creates an obligation to return, work out the next transition, prepare the next packet of context, and check that a newer run hasn’t invalidated an older review. The work is computationally parallel and cognitively serial.

A dashboard of running terminals makes the queues visible, but somebody still has to operate them. The missing abstraction is an execution graph that owns routine transitions and escalates only what needs a person. The aim isn’t maximum autonomy. It’s minimum unnecessary interruption: settle ambiguity up front, automate the middle, and bring human attention back where judgment changes the outcome.

Charrette is a control plane above coding agents. It owns the durable representation of the project and its tasks. Agents are workers, chosen for capability, availability, cost or trust.

Completion is backed by evidence

Acceptance criteria are part of the task before execution begins, and evidence is attached as the work proceeds. A task is complete when its claims are supported: tests passed against a named revision, an independent review examined that revision, visual evidence matches the deployed output, and remaining risks are either cleared or explicitly accepted. “The agent said it was done” is not an acceptance state.

“Agent orchestration” now describes almost any product with more than one agent in it. It helps to be precise, because the rungs below differ in kind, not just in degree.

A CI pipeline knows its stages in advance. Software work often doesn’t. An apparently small change can reveal a missing migration, a visual regression, an architectural disagreement or a security-sensitive path. A graph might begin as plan, implement, test. The first diff triggers independent review. A finding creates a repair node and a re-review. A flaky test branches into diagnosis rather than blindly retrying the implementation. A high-risk migration requires two reviews from different model families before it can be accepted.

The graph is dynamic, but its history stays inspectable: every plan revision, transition, worker selection and artifact keeps its provenance. The difference between the rungs is not how many agents run. It is how many decisions are made between them, and whether those decisions rest on evidence.

The two halves depend on each other. A graph with no memory has to rediscover policy on every run: which paths are sensitive, what counts as done, what was decided last time. A memory with no orchestration is a wiki: nothing supplies it, nothing tests it against the running system, and nothing notices when it contradicts itself. In Charrette, each run starts by reading project memory and ends by writing to it.

The expensive part of an interruption isn’t the minute it takes to answer. It’s the loss of focus: noticing a run has stopped, reloading its context, deciding, briefing the next agent, then finding your place in your own work again. Charrette draws a hard line around what’s allowed to spend that attention.

Many graph transitions aren’t writing tasks. They’re bounded judgments: does this result need repair, which specialist should review it, is the evidence sufficient, does this uncertainty warrant a person? TypeSafe’s September 2026 release of Jev introduces a model designed to return typed choices, scores and probabilities rather than text. Its interface is unusually relevant here.

The hypothesis is not that Jev should become Charrette’s coordinator. It’s that a fast, probabilistic decision model could become a supervision primitive used throughout the product, while the coordinator’s rules, state and history remain open and inspectable.

The boundary. A decision engine can’t turn a vague feature request into a useful graph, plan an implementation, write or deeply review code, diagnose a novel failure or resolve an architectural trade-off. Those remain jobs for generative agents and people. It is most valuable where the candidate answers can be defined in advance and the same narrow question is asked thousands of times.

Open interface, closed model. Jev is not open source; access is through TypeSafe’s hosted API, while its SDKs and a compatibility adapter built on ordinary LLM APIs are MIT-licensed. So the abstraction boundary matters. Charrette should own an open decision-engine contract and treat Jev as one optional provider, alongside constrained frontier models, smaller open-weight models and deterministic implementations. Project policy must never depend on an uncalibrated, provider-specific confidence scale.

An evaluation target, not a dependency. TypeSafe reports latency of roughly 70–500 ms, typed outputs, calibrated confidence and large cost advantages. Its published evaluations are company-run and use frontier-model consensus as the reference. A first benchmark should replay labelled events from real review, test and repair loops, and measure routing precision and recall (especially false acceptance and missed escalation), calibration, workflow outcomes, latency and cost at scale, robustness to contradictory or adversarial state, and portability across providers.

Dave Snowden, extending Michael Polanyi’s observation about tacit knowledge, puts it simply: we know more than we can say, and we can say more than we can write down. His paper “Complex Acts of Knowing” rejects the idea that organisational knowledge reduces to a complete repository of documents. For Charrette that is a design constraint. Project memory shouldn’t claim to capture everything. It should make the limits of its knowledge visible.

At team scale the problem gets harder. Context should be shared, but not all of it belongs at organisation level. A deployment policy may be shared; a temporary workaround should not be. The relationship between organisation, project and task is a research question, not just a database hierarchy.

Over the past year, the major AI coding companies have all moved from the agent towards the project around it: persistent knowledge, cloud tasks, review flows, multi-agent coordination. That validates the category. It also shows its incentive structure. Each vendor ties the project layer to what it sells.

Vertical integration is rational for each vendor and costly for each customer. A memory that moves cleanly to a competitor stops keeping customers, so no vendor has a reason to make its memory portable, or to route work to a rival’s model when that model is better this month.

The tools churn faster than projects do. The strongest coding model has changed hands repeatedly over the past eighteen months, and relative prices swing just as often. Open-weight models keep closing the gap, and new labs keep arriving. A team could spend weeks evaluating models and still not have an answer that holds for a quarter. Tying project context to one tool means paying for it at every switch.

Subscription economics favour an orchestrator of official tools. Frontier models are far cheaper through the subscription plans developers already hold than through metered API pricing. A layer that coordinates the official agent tools under their own terms passes that saving on. A layer that resells tokens can’t.

Independence is a quality feature. Review by a model from a different lab than the author catches failures the author’s model family shares. No lab can sell an independent reviewer of its own model.

Provider independence is often described as picking a model from a dropdown. That’s too shallow. If the project’s memory, orchestration policy, run history, acceptance logic and team conventions stay proprietary, the model is replaceable but the operating system is not. Charrette should be open because it sits in a privileged, durable position:

The business model

Charge for coordination and governance, never for compute. The open-source product is complete for an individual developer and serves as the adoption engine. Revenue comes from what teams need and self-hosting makes painful:

Because Charrette doesn’t resell model access, it adds to an existing AI budget rather than competing with it, and stays out of a price war with the labs. GitLab, Sentry, PostHog and Tailscale have followed versions of this model.

An annotated working set, not a neutral market ranking. Descriptions reflect public positioning; notes on gaps are our current assessment. Links were checked in September 2026.