Agentic Technical Debt and Where Orchestration Belongs in AI Agent Architecture

In 2015, a group of Google engineers published “Hidden Technical Debt in Machine Learning Systems” at NeurIPS. The paper’s best-known diagram showed the ML code as a small box inside a much larger system for data collection, configuration, serving and monitoring. Most of the cost of production machine learning sat outside that box, and agentic technical debt follows the same pattern.

In AI agents, the model call is the new small box. Around it sit prompts, tools, memory, retries, approvals, permissions, budgets and audit trails. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Gartner also predicts that over 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. Both predictions can come true at the same time.

Most agentic technical debt comes from placing retries, approvals, budgets and audit in the wrong layer of the architecture. This post maps the layers of an AI agent architecture, shows which layer should own each concern, and explains when a single agent needs nothing beyond its own runtime.

What Is Agentic Technical Debt?

Agentic technical debt is the accumulated cost of shortcuts around AI agents, where prompts, tool wiring, memory, control logic and governance rules are patched together faster than teams can test, standardize and audit them.

Several publications in 2026, from platform engineering teams to academic papers, catalogue these debt types in detail. The catalogues describe what goes wrong. The architecture question behind them is where each concern should live, so the debt does not build up in the first place.

Agents accumulate this debt faster than classic machine learning models:

• Non-deterministic output: the same input can produce a different result, which makes testing and regression checks harder.
• Actions on real systems: agents post to the ERP, send emails and change infrastructure, so a mistake has side effects.
• Long-running state: work spans minutes to days, including restarts and waits for people.
• Many owners: every team and every application vendor ships its own agents with its own rules.

The gap shows up in production numbers. In Camunda’s 2026 survey of 1,150 IT leaders, business decision-makers and architects, 71% said they use AI agents, but only 11% of agentic use cases reached production in the past year.

The Layers of an AI Agent Architecture

The diagram shows the layers of a production agent architecture and the decision gate above them.

Each layer has its own job:

• Model: reasons or decides. Depending on the task, this is an LLM, a decision model, a trained ML model or plain rules, as discussed in how decision models became a new AI category. LLMs come from Anthropic, OpenAI, Mistral in Europe, and DeepSeek and Alibaba’s Qwen in China, among others, and decision models from vendors such as TypeSafe AI.
• Agent harness: the runtime around the model for one agent. It runs the control loop, calls tools, assembles context, manages memory and sandboxes execution. The shorthand Agent = Model + Harness, popularized by LangChain, has become common for this split, and I covered the harness layer and its lock-in in detail in the AI agent harness and where vendor lock-in went. Frameworks such as LangGraph, the OpenAI Agents SDK, Google ADK and AWS Strands provide the building blocks.
• Durable execution: persists every step so a long-running run survives crashes, restarts and waits within one application. Temporal is the best-known example and runs LangGraph graphs and several agent SDKs as durable workflows.
• Unified orchestration control plane: one control plane for data, infrastructure, applications, and business processes. Agentic AI is governed across all four. The control plane starts work from events and schedules, sequences steps across systems and teams, and owns approvals, deadlines, compensation and the audit trail. Kestra is the example later in this post.

Above the stack sits the decision gate of process intelligence. It decides which processes get an agent at all and measures the impact afterward, as described in Process Intelligence Explained.

A harness belongs to one agent, while a business process runs across agents, people and systems for hours or days. Every layer is useful. Debt starts when one layer takes over the job of another. The boundaries do move, because every vendor grows into the neighboring layer: the model labs ship more harness features with their agent SDKs, durable execution vendors add agent integrations, and orchestration platforms such as Kestra add more durable execution capabilities. The ownership question in the next section stays the same whichever product ends up providing a layer.

Where Each Concern Should Live

The matrix assigns the most common concerns to the layer that should own them, independent of which products you choose for each layer.

• Model choice: the orchestration step decides which kind of model a task needs, and the harness routes the call. I described this split as “decide high, route low” in my post on multi-model AI orchestration.
• Tool permissions and identity: the harness enforces them on every call. The control plane defines which identity and which secrets a workflow step may use.
• Retries and timeouts: the harness retries model and tool calls without side effects. Steps that change a business system are retried by durable execution or the control plane, keyed on a business ID so a retry cannot post the same booking twice.
• State after a crash: durable execution recovers state inside one application. The control plane recovers state across systems.
• Human approval: the control plane owns it as an explicit step with a timeout, an escalation path and a record of who approved what.
• Cost and token budgets: the harness caps a single run. The control plane enforces budgets per process, team or tenant. Budgets also limit the damage from stolen credentials. In the LLMjacking incidents Mandiant investigated in 2026, attackers ran up more than 100,000 US dollars in model charges in a single day.
• Compensation across systems: the control plane owns it, because only the control plane sees every system the process touched.
• Event and schedule triggers: the control plane, for example reacting to Kafka topics as shown in event-driven workflow orchestration on Apache Kafka with Kestra.
• Audit and lineage: the control plane records inputs, outputs, decisions and approvals of every step across all four domains.

Common Placement Mistakes That Create Debt

Most debt I see in agent projects comes from a few patterns:

• Approval rules in the prompt: “Ask before refunds above 1,000 euros” in a system prompt works most of the time. Nobody can prove it worked every time.
• Retries in the agent loop around side effects: a timeout on an ERP call leads the agent to try again, and the supplier receives two credit notes.
• Audit in one framework’s traces: each team sees its own agent, but nobody can reconstruct the end-to-end process for an auditor.
• Governance inside every vendor’s box: the ERP, the CRM and the service desk each ship agents with their own guardrails. The process crosses all of them, and no single rule set covers it.

Placing Each Concern in a Supplier Invoice Dispute

A supplier invoice dispute is a good example of how the layers work together. The flow marks which layer owns each step.

• An invoice mismatch event from the ERP arrives on a Kafka topic and starts the workflow.
• A deterministic three-way match compares invoice, purchase order and goods receipt. Most cases end here without any AI.
• A decision model classifies the remaining disputes by type, for example price, quantity or missing delivery.
• An LLM agent runs in its harness with read-only tools for contracts and order history. It drafts a resolution and a message to the supplier.
• Above a defined amount, a person in accounts payable approves or edits the proposal. Without a response before the deadline, the case escalates.
• The credit note goes to the ERP and the message to the supplier portal in parallel. If the portal update still fails after retries, the workflow reverses the credit note and opens a case.
• Every step, input, model decision and approval lands in one audit record.

The agent does one bounded step in the middle of a governed process, and it never decides alone whether money moves.

Running the Control Plane with Kestra

Kestra, the open source orchestration platform makes this concrete. The flow is declarative YAML in Git. The agent runs as one AI Agent task with an explicit tool list, a cap on tool calls, a token budget for the whole run and a timeout. The approval is a Pause task that waits for a person and resumes with the decision. A Kafka trigger starts the flow. Workers run close to the ERP and the data, while the control plane can run anywhere.

Most teams start Kestra in one domain, often a data pipeline or an infrastructure job, because the core is lightweight, event-driven and Apache 2.0 licensed. A process like this one is usually the second or third flow, once the first domain runs.

Other orchestrators can fill parts of this role. Many enterprises run several of them side by side, and they call each other where a process crosses domains. Camunda is strong when business teams model the process in BPMN. Temporal fits when developers write the whole process as application code. Airflow and Dagster cover data pipelines well, and cloud services such as AWS Step Functions work inside one cloud. Each is a good choice within its domain. Kestra covers all four domains with one control plane, so the same audit trail also includes the pipeline that refreshes supplier master data and the job that rotates the ERP credentials.

When a Single Agent and Its Harness Are Enough

Not every agent needs a control plane. A coding assistant, a research agent or a support summary inside one application is well served by its harness. If an agent runs for a long time within one team’s application, durable execution is the right addition.

A control plane earns its place when at least one of these applies:

• The process crosses several systems or teams.
• An agent action moves money, changes production systems or reaches customers.
• An auditor or regulator needs an end-to-end record.
• Agents from different vendors work on the same process.

Where the Value Moves When Models Commoditize

The model layer is commoditizing fastest. Decision models showed the pattern. Several vendors shipped compatible offerings within weeks of the first launch. Value moves to the layers that hold process state, approvals and the audit record, because they are hard to replace once a process depends on them.

Several groups compete for that layer. Hyperscalers bundle managed agent runtimes. Durable execution vendors add agent integrations. Application vendors embed agents in ERP, CRM and service management. Orchestration platforms govern processes across all of them. The practical question for every agent project is which layer owns approvals, budgets and audit. It is worth answering early, because moving these concerns later means rebuilding the process around them.

The 2015 Google paper on hidden technical debt in machine learning made the case for engineering the system around the model. Agents need the same discipline. Unified orchestration gives every concern around the agent a clear owner, which keeps agentic technical debt visible and under control.

To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.