Why I’m building an orchestration engine in public

Where processes break

Picture a supplier onboarding request halfway through its journey. An AI agent has validated the information. A manager has approved it. An automation has submitted data to another system. Then something changes, or a response never comes back.

Progress stops.

Before anyone can move forward, they need answers. What was approved? Did the action actually succeed? Would retrying it resolve the issue or create a duplicate? Which facts were reviewed, and do they still apply?

That's the problem I'm building Canonik to address.

Throughout my work in analytics, procurement, and AI enablement, I've run into the same challenge repeatedly. Individual capabilities are easy to demonstrate. An agent can analyze a document. An automation can create a ticket. A person can make a judgment. Each works well in isolation.

Business processes are much harder to govern. The difficulty begins when those capabilities are combined, and it grows with every AI agent added. Each participant may keep a record of its own activity, but accountability needs one answer that spans all of them.

Finance, procurement, and audit teams feel this first because the consequences are tangible. An approval covers a specific amount, supplier, or set of terms. If those facts change, the approval may no longer apply. If a system never responds after receiving an instruction, a retry could create a duplicate. A process can look complete while leaving a critical obligation unresolved.

Large enterprises rarely operate within a single ecosystem. Work flows across ERP platforms, procurement systems, ticketing tools, custom applications, external partners, and increasingly multiple AI agents. Existing platforms are powerful within their own boundaries; the gaps appear between them. Organizations need an orchestration layer that maintains continuity across those boundaries and preserves accountability throughout the process.

The idea started becoming concrete when I realized that, in some of these situations, no system was actually wrong. Every participant could explain its own piece of the process. The problem was that none of them could explain the whole thing.

A record of the work, and the reasons behind it

Canonik is a neutral system of record for work performed by people, AI agents, and enterprise systems. It maintains the state of a request, determines what can happen next, and preserves the evidence behind every transition.

The goal is straightforward: if work is important enough to govern, it should be possible to understand where it stands, how it got there, and why each decision was made.

The platform is early, and this series will distinguish between implemented behavior and open design decisions. But several foundational principles are already clear.

The first is that unknown is not false.

Suppose a supplier request requires a security review if the supplier will handle sensitive information. An unanswered question cannot safely be read as "no review required." The workflow must recognize that information is missing and obtain an answer before proceeding.

That sounds obvious in business language. It must be equally explicit in the engine.

The second principle is that an agent's credentials never authorize it to approve on a person's behalf.

An assistant may help someone understand a request, gather supporting information, or present an approval action. The decision itself must still belong to an authenticated, authorized individual, tied to the facts they reviewed when they made it.

These principles shape how work moves through the system, and what can be proven afterward without reconstructing events from scattered conversations, logs, and system histories.

Why build the engine myself?

My first major architectural decision was to own the orchestration engine.

The engine determines how work advances, waits, retries, returns for correction, recovers from failure, and reaches completion. Those behaviors are not implementation details. They are the product, and owning the engine gives me direct control over them and over how external systems integrate with them.

That decision carries a real cost. An existing workflow engine would reduce the engineering burden. Building my own means taking responsibility for scheduling, concurrency, durable timers, retries, cancellation, and recovery, and proving those behaviors stay correct when conditions are less than ideal.

The initial implementation uses TypeScript and PostgreSQL, with the database holding both durable state and outbound jobs. A state transition, its recorded event, and the instruction to perform the next action commit together as a single unit of work.

External interactions need additional safeguards, because a database transaction cannot tell me whether another system completed an action after its response was lost. That boundary is exactly where orchestration systems prove their value or reveal their weaknesses, and I want to understand it by building, testing, and observing it directly.

Why build in public?

I've been thinking about this problem for nearly a year. I spent a lot of that time developing the concept, refining the architecture, and examining edge cases.

I didn't build it.

Refining the concept had become easier than proving it against reality. Building in public is how I'm changing that. It forces me to show progress, document trade-offs, and test assumptions against real code, and it leaves a record of judgment: what I chose, what I deferred, what failed, and what evidence changed my mind.

I also want a deeper, hands-on understanding of the tools involved: configuring environments, connecting services, debugging failures, and tracing behavior through the system. I'll use AI assistance throughout while remaining responsible for understanding and validating the results.

Two small lessons from day one

The starting stack is TypeScript 7 and PostgreSQL 18, developed in Linux on Windows, with Docker for local services and GitHub Actions for automated checks.

The first automated check failed because three files were missing a final newline.

My first reaction was equal parts relief and annoyance. At least the pipeline was working; it had just proven it by catching a mistake I hadn't seen.

It was a trivial formatting issue, but the principle scales: define the requirement and verify compliance. Business controls just operate at a different size.

The second lesson was that a running database container is not necessarily ready to accept connections. "Started" and "ready" are not the same thing. Software that connects to it has to account for the difference, and so does workflow orchestration: progress should depend on evidence that a dependency is actually ready, not an assumption that it probably is.

What comes next

The next milestone is the engine core: a workflow that can advance through tasks, record decisions, and survive a restart without losing state. Once that foundation is in place, I'll start introducing failures deliberately and measuring how recovery behaves.

I'll document the results here, including the decisions that don't survive contact with implementation. The point of this series isn't to defend my design. It's to test it in the open.

When an AI agent touches an approval in your organization, how would you prove what was actually approved?