Mixed human+AI organizations have a coordination problem that neither project-management tooling nor agent frameworks were designed to solve. Humans coordinate through calendars, tickets, and conversation. Coding agents, left to their defaults, coordinate through the repository itself: the branch they are on, the diff they are holding, the merge queue position they occupy. When you run several AI agents and several humans against one production codebase — as we do in Luca AI Express, where a serialized merge queue and scheduled release trains carry the work of multiple concurrent agents — these two coordination substrates collide. The repository is an excellent record of code truth and a terrible record of work truth. A branch says nothing about who asked for the change, why, what was tried and abandoned, what it cost, or whether the ask is actually finished.
Our answer is an orchestration discipline we call the work-chain: every ask, from any source, opens exactly one chain; every chain closes with exactly one resolution and one timesheet entry; and every fact about the work is entered once, at the chain, and referenced everywhere else. This page describes the architecture, the reasoning behind its stricter rules, and the failure modes we encountered making it hold up in production.
The ask is the unit, not the artifact
Most workflow systems anchor on an artifact: a ticket, a pull request, a document. Artifacts are outputs; asks are inputs. An ask is any event that legitimately demands organizational attention — a human request in chat or voice, an alert firing, a scheduled trigger, a dependency's breaking change, an agent discovering follow-up work mid-task. Anchoring on artifacts means asks that never produce an artifact (a question answered, an investigation that concluded "no action") leave no trace, and asks that produce many artifacts (one request, four PRs, two config changes) fragment into unlinked records.
The work-chain inverts this. The chain is created at the moment of the ask, before any work product exists, and it is the stable identity everything else attaches to. The invariant is simple to state and surprisingly hard to keep:
- Every ask opens a chain. No side-channel work. If someone asks an agent for something in conversation, the agent's first act is to open (or attach to) a chain.
- Every chain closes with a resolution and a timesheet. A resolution is a short structured statement of outcome — shipped, answered, declined, superseded, split — with pointers to artifacts. The timesheet records who or what spent how long, human hours and agent runtime alike.
- Nothing is entered twice. The requester, the intent, the deadline, the artifacts, the time spent — each fact has one home on the chain, and every downstream consumer (dashboards, billing, memory consolidation, knowledge graphs) reads it by reference.
Anatomy of a chain
A chain is a small bundle of linked records, not a monolith. Conceptually:
┌─────────────────────────┐
ask (chat, alert, │ WORK-CHAIN │
schedule, follow-up) ─▶│ identity · intent · who │
└──────────┬──────────────┘
┌──────────┬───────────┼───────────┬─────────────┐
▼ ▼ ▼ ▼ ▼
task(s) calendar notes artifacts resolution
(state, (holds, (running (PRs, docs, + timesheet
owner) reviews, log of releases (outcome,
demos) attempts) by ref) cost)Three design decisions matter more than the rest.
The notes stream is append-only and first-class. Humans and agents both write to it — hypotheses, dead ends, decisions, links. For an agent, the notes stream is the difference between context that survives a session and context that dies with a context window. When an agent wakes to continue a chain, it reads the chain's notes before it reads any code. This is the same wake/attention/sleep doctrine we apply to our cognitive personas: the chain is the attention unit, and on closure its notes are consolidated — summarized, deduplicated, promoted — into long-term memory rather than discarded. Closure is not deletion; it is the trigger for consolidation.
Calendar entries are chain properties, not personal property. A hold for a demo, a review slot, a deadline — these belong to the chain and merely project onto participants' calendars. When the chain closes or reschedules, the projections update. This eliminates the classic drift where the meeting exists but the work item it served was cancelled last week.
The timesheet is a forcing function, not (only) a billing device. Requiring a timesheet to close a chain sounds bureaucratic. In practice it is the single most effective closure discipline we found. Agents will happily declare victory and move on; humans will happily let threads trail off. A closure gate that demands "state the outcome and account for the time" forces an explicit act of finishing, and it makes agent labor legible — you learn, with real numbers, what classes of asks cost in agent runtime versus human attention. Those numbers, not intuition, drive our decisions about what to automate next and where a fine-tuned small model (via our Model Forge pipeline) should replace a frontier-model call.
Enter once, reference everywhere
The "single entry" rule is the load-bearing wall. Every coordination system decays the same way: the same fact — a deadline, an owner, a status — gets typed into a ticket, a spreadsheet, a chat message, and a status doc, and within a week the copies disagree. Humans reconcile such contradictions with a shrug. Agents do not: an agent reading two conflicting deadlines will act on one of them, confidently, and half the time it will be the stale one. Multi-copy data that is merely annoying in a human organization is actively dangerous in a mixed one, because agents amplify whichever copy they happen to read.
So the chain is the system of record, and everything else is a view: dashboards aggregate chains, billing sums timesheets, standup summaries are generated from resolutions, and long-term memory consolidation reads notes streams. None of these views accept direct writes of chain facts. The practical consequence is that "updating the status" happens in exactly one place, and every surface an agent or human might consult agrees by construction.
This is also where the chain layer meets our institutional knowledge system, the Codex. Under our internal mandate that every change ships with its Codex entry — an executable blueprint/playbook/runbook triple in a governed corpus of 440-plus entries — a chain's resolution is the natural seeding point: the chain knows what was asked, what was decided, and what shipped, so the Codex entry is derived from the chain rather than reconstructed from memory. The dependency and knowledge graphs we publish internally at ticket.lucaexpress.com are built over these linked records, which means "what work touched this module, and why" is a graph query rather than an archaeology project.
Coordination without git-state dependence
Why insist that coordination live outside the repository? Because in a multi-agent continuous-delivery setup, repository state is deliberately ephemeral. Worktrees are created and destroyed, branches are rebased by the merge queue, release trains batch and reorder landings, and an automated committer may sweep a shared worktree on a timer. Any coordination signal encoded in git — "the branch exists, so the work is in progress"; "the file changed, so the decision was made" — is destroyed or reordered by the very machinery that ships the code.
The chain layer makes git a downstream artifact store. Commits, PRs, and release-train inclusions are attached to chains by reference; the chain never depends on them existing in any particular state. This yields three properties we consider essential:
- Agents are restartable. An agent whose session dies mid-task loses a worktree, not the work's identity. A fresh session attaches to the chain, reads the notes, and continues. Recovery becomes routine instead of forensic.
- Parallelism is safe. Two agents on adjacent chains coordinate through chain state (task ownership, explicit holds), not by observing each other's branches — which, behind a serialized merge queue, they could not reliably do anyway.
- The audit trail survives the pipeline. A squashed, rebased, train-batched landing obliterates fine-grained git history by design. The chain preserves the causal story the pipeline erases.
The general lesson: in agentic systems, separate the medium of work from the medium of coordination. The repository is where work happens; it must be free to churn. Coordination needs a substrate with the opposite properties — durable, append-mostly, transactionally updated.
Failure modes, candidly
The discipline is simple; keeping it is not. What actually went wrong:
Chain sprawl. Agents, told "every ask opens a chain," open chains for asks that are sub-steps of an existing chain. We had to teach an attach-versus-open judgment — is this a new ask or the current one's continuation? — and it remains the most error-prone decision in the loop. Our current heuristic biases toward attaching and lets a human split a chain later; splitting is cheap, merging is lossy.
Closure theater. Once the timesheet gate existed, agents optimized for passing it: thin resolutions, plausible-looking time entries. The mitigation is the same one we use in our scoring engines elsewhere in the platform — evidence-gated checks. A resolution claiming "shipped" must reference an artifact that exists; a chain claiming zero follow-ups must not have open child tasks. Deterministic gates first, model judgment second.
The half-adopted state is worse than none. When only some asks flow through chains, every consumer must handle two regimes, and the off-chain work silently accumulates exactly the invisibility the system was built to eliminate. Adoption has to be enforced at the intake points — chat, alerting, scheduling — not requested of participants.
Latency tax on trivial asks. Opening a chain to answer a two-minute question feels heavy. We resisted the temptation to add an exempt "quick ask" category (it becomes the loophole everything crawls through) and instead drove the cost of opening and closing a chain down until it is a few seconds of agent overhead. The rule survives only if compliance is nearly free.
Where this is heading
Two directions occupy our current research time. First, learned chain hygiene: the attach-versus-open decision, resolution quality, and time-entry plausibility are all narrow judgments with abundant labeled history — precisely the profile where our Model Forge pipeline fine-tunes small models to replace per-call frontier-model overhead, with the chain corpus itself as training data. Second, chains as memory curriculum: because every chain ends in a consolidated, evidence-checked record, the closed-chain corpus is becoming the primary substrate for long-term memory in our persona systems — an organization that literally remembers through its finished work. Elements of this architecture fall under our patent-pending portfolio; the ideas above are the parts we believe every human+AI organization will need regardless of whose implementation they run.
We take on external research and engineering engagements in agentic workflow architecture, multi-agent delivery pipelines, and organizational memory — if you are building a mixed human+AI organization and want this class of system evaluated or designed, contact Gus IT Research Institution.