This post introduces Invoker, an alpha developer preview I have spent the last few weeks building. It is still early and not yet polished, but I wanted to share it now to get initial feedback.
https://github.com/Neko-Catpital-Labs/Invoker
Invoker is an open-core execution engine for AI-driven engineering workflows. Unlike agent tools that revolve around a transient chat session, Invoker treats work as a durable workflow: each step runs in an isolated environment, state transitions are persisted, intermediate results are inspectable, and humans can approve, retry, fork, or redirect execution at explicit control points.
The goal is not just to generate code, but to make AI-driven work and each step in it reproducible, auditable, and operationally controllable.
If that sounds closer to a build system, that is intentional.
Once you move beyond early AI coding demos and try to use these systems in real engineering environments, something becomes obvious: code generation is no longer the primary problem. Neither is spinning up tens of agents to do your work for you in the background.
Execution is. Particularly correct execution.
The bottleneck to this is not whether models can produce quality code. It is whether humans can maintain a coherent picture of what actually happened: which branch contains the real fix, which run produced the trustworthy result, whether a summary can be trusted, whether the right factors were considered, or whether an agent silently drifted. And if these things do happen, when did it happen and can we recover from it?
At some point, AI-powered development stops feeling like programming and starts feeling like operational management of nondeterministic systems. That kind of thrashing leads to burnout, wasted effort, poor judgment, and lower-quality code.
Much of the public narrative still assumes the answer is to aggressively double down on AI: better reasoning, larger context windows, faster inference, more agents. But even as models improve, much of the gain is consumed by coordination friction, supervision overhead, and workflow complexity.
The popularity of systems like Gastown and Claude-managed swarms signal that the problem is already shifting away from generation and toward execution management.
Where I disagree with the current zeitgeist is with the idea that nondeterministic AI systems should be managed primarily by layering more nondeterministic AI on top. Nor do I agree that firing more unmanaged slop cannons solves the underlying problem.
Invoker is a bet not on what AI might become, but on what will remain necessary regardless of model progress: safety, visibility, reproducibility, control, and operational clarity.
Software engineering has solved similar problems before. Build systems, CI, and workflow engines emerged not because compilers were too weak, but because execution needed structure. Determinism had to be imposed on complex systems before they could scale.
AI development is approaching the same inflection point. We are taking inherently nondeterministic systems and trying to insert them into deterministic engineering environments without the scaffolding those environments require.
We are treating them like conversations when they behave much more like long-running, failure-prone workflows.
That gap is why Invoker exists.
Features
Invoker is designed to let you:
- Break work into discrete tasks. Smaller units of work are easier to inspect, retry, and control. They also reduce unnecessary context transfer, which can materially lower model usage and cost.
- Route tasks to specific environments and models. Different tasks require different levels of capability, isolation, and cost. Invoker supports routing rules so routine work can be delegated to cheaper models and appropriate execution environments automatically, while more demanding steps can be reserved for stronger models.
- Modify, reproduce, cancel, retry, or fork work in progress. Execution is not treated as a one-shot agent run. You can intervene midstream, rerun steps, branch from intermediate states, or stop work entirely when the workflow needs to change.
- Build stacked workflows and stacked diffs. Multi-step changes can be expressed as explicit workflows, making it easier to manage dependent tasks and reason about layered code changes.
- Inspect and audit tasks in flight. Running work remains visible and controllable. You can review the intermediate state, understand what happened, and step in when human judgment is required. You even have the ability to fix and repair the work of agents with a different agent from a different model or service.
The Reliability Problem
If you ask engineers why they still hesitate to trust AI with important work, the answer usually is not that the model is useless. It is something more operational and more serious:
- “I don’t know what it actually did.”
- “I don’t know whether this is the right branch.”
- “I don’t know if I can reproduce the run that got the good result.”
And, increasingly:
- “The output quality degraded and I don’t know why.”
These are not complaints about intelligence. They are complaints about reliability, lineage, visibility, and control. They are infrastructure problems wearing AI clothing.
Engineering organizations do not scale on brilliance alone. They scale on predictability, repeatability, observability, and accountability. When AI enters serious workflows, those properties matter more, not less, because the thing producing output is probabilistic, context-fragile, and often confidently wrong.
Capability gets the demo. Reliability gets adoption. Exaggeration gets retweets.
There is also a hidden tax people mismeasure. When people talk about the cost of AI, they usually point to tokens because token billing is visible.
That cost is real, but it is not the only one, and often not the largest.
In many workflows, the larger cost is human orchestration overhead. Running multiple agents often feels less like automation and more like supervising a room full of extremely fast junior engineers who constantly need redirection, verification, restarts, and synthesis. And to my knowledge, there is no management literature arguing that the most efficient form of an operation is hiring an army of junior engineers to check the work of other junior engineers.
Yet that’s what the industry has declared with AI.
You have to remember what each one was doing. Compare outputs. Decide which branch or experiment to keep. Preserve the chain of why something failed. Recover when context compaction silently drops a critical fact.
All of that consumes the scarcest resource in engineering organizations: human attention. Organizations shouldn’t be buying lines of code. They should be buying well thought out and efficient execution.
That is the real paradox. AI promises leverage through parallelism, but unmanaged parallelism destroys careful thought and, with it, trust in the work. The bottleneck stops being code generation speed and becomes supervision bandwidth.
If AI is going to scale inside real engineering organizations, it cannot require more operational attention than it saves. Its execution model has to justify its costs, and the first step is being able to measure what actually happened.
Which means execution has to become structured, inspectable, recoverable, and measurable.
Existing AI Orchestration Feels Fragile and Homogenous
Much of today’s AI orchestration tooling operates on an implicit theory: give the system enough context, enough retries, and enough optimism, and eventually something correct will emerge.
To be fair, this works better than it has any right to for one-off tasks. Genetic programming as a paradigm exists, and repeated mutation plus selection can produce surprising results. It is not unreasonable to think a similar dynamic can sometimes work for code. Repeated prompting often does produce something useful.
As a full admission, I vibe coded Invoker. That should speak to how powerful AIs can be.
But fully trusting AI not just on results but execution? We are not there yet. Results vary by model, by session, by prompt phrasing, by sheer luck, and by whatever experiments the model providers decide to run that day.
If the work is disposable, if nobody needs to audit it later, and if you do not care which of five branches actually contained the good change, chaotic agent loops can get you surprisingly far.
That is why many multi-agent systems today are thin orchestration layers around several model sessions, presented as autonomous engineering systems. They quickly get traction for being able to spin up code but running several sessions still faces the coordination tax and the results remain untrustworthy unless you blindly trust it.
When the work stops being disposable, the problems start. Once runs last longer, spawn experiments, touch multiple environments, depend on prior outputs, or require human judgment at real decision points, the “retry until it works” model starts to show its limits.
Failures are no longer just failures. They go silent. Context drifts. Summaries replace primary artifacts. Outputs get carried forward even as their provenance becomes unclear. You find yourself staring at something that looks like progress while quietly wondering whether it is actually just accumulated error wrapped in a clean UI.
Traditional software engineering learned this lesson the hard way. Reliable systems enforce boundaries: isolation, explicit state, telemetry, recovery points, and reproducibility.
The important question is never just what happened, but what happened, in what order, in which environment, and whether it can be reproduced.
AI tooling often behaves as though it can skip that chapter.
Invoker disagrees. It treats AI workflows less like conversations and more like unreliable builds: something that must be isolated, tracked, recoverable, and reproducible. The goal is not to make agents smarter. The goal is to make their execution legible.
Because historically, when software becomes unreliable, we do not solve that by adding more optimism. We solve it by adding structure and control.
Build Systems as a Mental Model
If it isn’t clear by now, I firmly believe the dominant mental model for many AI orchestrators is flawed.
Most systems take a nondeterministic generator and try to correct it with more nondeterministic checks and guardrails. The result is higher cost and a system that often degrades in reliability as complexity increases.
Errors do not disappear. They compound. Over a long enough chain of events, even small degradations accumulate and can render an “agentic-first” autopilot workflow worthless.
To me, this is the equivalent of trying to fix flaky tests with more flaky tests. You spend more money and trust the system less.
The alternative is not simply better models. It is better structure.
Invoker starts from a different premise: nondeterminism must be isolated, not recursively corrected. Flaky execution cannot be allowed to contaminate the rest of the system. It must be sandboxed, evaluated, and either promoted or discarded based on explicit correctness criteria.
That leads directly to a familiar set of questions, ones distributed systems and build infrastructure have already spent years answering:
- How do you isolate execution?
- How do you parallelize safely?
- How do you observe work in progress?
- How do you recover from partial failure?
- How do you prevent downstream consumers from reading corrupted outputs?
In AI workflows, these are not edge cases. They are the entire problem.
Once you accept that, the architecture stops looking like “agent conversations” and starts looking like an operational system: a living execution graph with explicit state transitions, controlled mutation, and defined decision boundaries where humans determine what becomes durable.
That execution graph is the core abstraction of Invoker.
The persisted state is the source of truth, while the in-memory graph is a synchronized cache of that state. The UI, transcripts, and agent summaries are views, not authority.
That distinction is foundational.
When state is explicit and durable, workflows can be resumed instead of reconstructed. Failures can be retried along known execution paths instead of manually recreated. Experiments become concrete branches that can be compared and merged. Review boundaries become real state transitions instead of social agreements.
Reliability no longer depends on human memory. It depends on system structure.
Operating Invoker
It helps to get concrete, because “orchestration infrastructure” can quickly dissolve into abstraction.
In practice, Invoker is not just a planner, not just a terminal multiplexer, and not just a wrapper around coding agents. It is a control plane for AI-driven workflows.
Workflows can be submitted as DAGs of tasks, whether authored directly by humans or generated by planning agents. Those workflows materialize as mutable execution graphs that can be inspected through the UI, queried through headless interfaces, or driven through integrations like Slack. The important detail is not the number of surfaces. It is that every surface operates against the same execution model rather than maintaining its own private reality.
Tasks are not confined to a single toy environment. Invoker supports execution across local worktrees, containers, and remote machines. Once execution location becomes part of the durable task definition, the system starts to resemble workflow engines and build systems more than chat tooling.
Failure is treated as a normal operating condition rather than an exception. Branching, retries, reconciliation, and merge gating are explicit operations. Recovery is meant to be routine rather than an improvisational exercise performed by one tired engineer juggling terminals and transcripts.
Human decision points are also first-class. Approval states, review gates, and merge controls make human judgment part of the workflow itself rather than an external process people try to remember to follow.
Auditability follows naturally from this structure. Tasks have lineage. Agent sessions are preserved. Events are persisted. Recovery flows maintain identifiers so work can be inspected later instead of reconstructed from memory.
None of this guarantees perfection. It simply means the system is designed so that “what happened?” has a better answer than “I think it was the branch or workspace from earlier, unless I’m confusing it with something else.”
Philosophy
Underneath the implementation details is a simple design philosophy:
Agents generate possibilities. Humans decide which possibilities become durable decisions.
Many AI tools and organizations invert this relationship. They encourage exploration first and governance later. That can work when the cost of being wrong is low. It breaks down when reliability and correctness start to matter.
Invoker is built on the assumption that speed and control are not opposites. Exploration can happen inside the workflow. Experiments can branch. Tasks can run in parallel. Some messiness in the middle is inevitable, because real systems always have some messiness, slop, and tech debt.
What matters is putting hard edges around the moments where humans must approve, merge, reject, or restart. Those boundaries are what keep acceleration from collapsing into chaos.
In other words:
Invoker is not trying to make agents responsible. It is trying to make their execution governable.
Why This Matters
Saying AI needs build system harnesses does not mean AI workflows become deterministic. They will not, and that is not the point.
The point is to move AI execution out of experimentation and into infrastructure.
Once you do that, the conversation changes. AI stops being a political football and becomes an operational question: not whether it can produce output, but whether that output can be trusted, governed, and priced.
This is where most current tooling falls short. It optimizes for generation, not operation. Incentives, both inside organizations and online, still favor flashy demos over boring, reliable systems.
Invoker is a bet that AI workflows will follow the same path as every other critical software system: from experimentation, to operations, to governance.
If AI adoption accelerates, organizations will need ways to control growing fleets of workflows, environments, and costs. If adoption slows or becomes selective, they will still need ways to make the workflows they trust reliable and auditable.
And if AI quality degrades under economic pressure, organizations will need a way to measure that degradation instead of relying on anecdotes and complaints. Many issues are ignored simply because there is no systematic hard evidence or a reproduction case.
Either way, execution discipline becomes more valuable and with Invoker, you have both the evidence and reproduction. In any debugging endeavor, reproduction is half the battle.
Eventually, as all new technology matures, the conversation shifts from engineering curiosity to financial accountability and pragmatism:
- Where is the money going?
- Which workflows consumed resources?
- Which execution paths were expensive?
- Which series of prompts paid off? Which ones did not?
- Can we get the same results with different models?
- Can we get 80% of the results for 20% of the cost?
These are not questions about prompts. They are questions about operations that every serious manager should already be asking themselves.
Once AI becomes operational, orchestration stops being a developer convenience and becomes economic infrastructure.
Invoker is built around the assumption that this transition is inevitable.
Law As A Boundary
If you have made it this far, you have probably read the license in the repo. It is a particular one. Apache 2.0 is the base. If the code breaks your environment, that is not my liability.
On top of that sits a time-bound restriction through the Functional Source License: for two years, Invoker cannot be commercially rewrapped and resold. After that, it reverts fully to Apache 2.0.
The restriction is narrow. It does not limit commercial use of Invoker itself. You can build with it, generate code with it, run a business on top of it. I have no claim over that output or those profits. The constraint is only on repackaging and resale. That deviation from open source norms is intentional.
The more unusual part is the clause around layoffs:
“Except for evaluation or testing, You shall not use the Software to replace employees or to reduce headcount for roles performing substantially similar functions, for six (6) months following your first use of the Software”
The intent is simple: prevent premature conclusions for both the software and for the capacities of AI.
The boundary between experimentation and real use is messy. This license does not try to perfectly define it. It draws a line and leaves the edge cases visible.
Individual use is unconstrained. Experimentation, piloting, vetting, and trying out the software at scale is not a violation of the clause.
But the moment usage begins to affect how work is performed, organized, recommended, or taken seriously as a first class citizen at scale, the situation changes.
At that point, a claim is being made: that AI-assisted execution is reliable enough to enter the operating model. The restriction applies to the action itself. For the defined period, the Software cannot be used as a basis for reducing headcount in equivalent roles.
The reasoning is straightforward. AI productivity is measured through proxies that are easy to inflate: tokens, lines of code, commits. They are legible. They are not reliable. Once targeted, they degrade.
Invoker exposes that gap. It shows what was attempted, what worked, what failed, and what it cost. Not to make AI deterministic, but to make it observable.
The six-month window is a forcing function. If the gains are real, they will persist under observation. Acting before that is not optimization. It is speculation. The window is not precise. It is sufficient to force observation before action.
Because this is not ideological. It is a measurement constraint.
Tech has avoided the labor dynamics seen elsewhere because compensation and mobility made it unnecessary. AI puts pressure on both.
That is why proprietary rewrapping is restricted during the initial period. Without it, these constraints are the first thing an intermediary removes.
This license makes the trade explicit: experiment freely, but do not institutionalize claims you have not yet measured. If AI is infrastructure, its impact should be observable, time-bound, and real.
Closing
At its core, Invoker and its license ask a fundamental question:
If coding becomes cheap, then more code is not necessarily evidence of progress. It may just as easily be evidence of unmanaged complexity, weak execution, or incentives that reward output over judgment. In that world, the best engineers are not the ones who produce the most code, but the ones who reduce the amount of code and coordination required in the first place. Their role is not merely to solve problems, but to remove the conditions that keep generating them. Most organizations still reward the opposite.
So the real question is this: are engineers capital, or labor? Are they builders of long-term organizational capability, or simply workers paid to execute tasks?
Invoker exists in part because the industry has avoided answering that question directly. Companies speak confidently about AI, productivity, and leverage, but rarely subject those claims to the standards of real engineering: control, measurement, repeatability, and accountability. Either they lack the technical maturity to operationalize those beliefs seriously, or they are more interested in the labor narrative than the engineering one.
Invoker forces a clearer answer. If AI meaningfully reduces cost, improves output, or increases engineering leverage, then those gains should be measurable and legible. That is what serious engineering organizations do. They validate claims through disciplined execution, not slogans, and certainly not as cover for headcount decisions. Someone is going to be wrong here, whether it is engineering management or the skeptics, but the answer should be established honestly.
If you are interested in contributing, consider opening a pull request. Invoker is still in developer preview, not yet ready for a 1.0 release, and there is no shortage of bugs or performance issues still to be worked through.
Part 2: Invoker’s Architecture