Peter Birkholm-Buch

Stuff about Software Engineering

Month: September 2026

Agent Orchestration Is a Capability, Not a Platform

2026-09-16 /

We should not confuse agent orchestration capabilities with an Agent Orchestrator platform. The enduring architecture is simpler: expose enterprise capabilities through thin, governed APIs; let authorized AI harnesses discover and compose them; and treat the harness as the Agent Runtime rather than as a mandatory central platform.

That means:

  • REST/OpenAPI for service contracts

  • OAuth/OIDC for identity and authorization

  • MCP or equivalent open mechanisms for machine-readable discovery where useful

  • the harness for execution, skills, scheduling, state, policy and orchestration

The harness might be a coding assistant, a local application, a cloud service, a domain-specific runtime or a custom application. The capability should survive replacement of any one of them.

I’m not disputing the need for orchestration capabilities; I’m disputing the assumption that those capabilities imply an enterprise Agent Orchestrator platform.

The market framing

The market is converging around the idea that enterprises need an orchestration or control layer for AI agents. Gartner describes a fragmented market in which BOAT, BPA, AI agent platforms, iPaaS and open-source frameworks can all provide agent orchestration, and frames the emerging competition as one over control of enterprise execution:

McKinsey uses the term agentic mesh for a composable, distributed and vendor-agnostic orchestration layer connecting agents and traditional systems. Its proposed capabilities include discovery, registries, authentication and authorization, observability, evaluations and governance. It also identifies repeatable and executable actions through secure APIs as foundational infrastructure for agentic systems:

There is clearly a real set of capabilities here. The questionable step is the move from capability to mandatory central platform.

Old wine in new bottles

This closely resembles the integration-platform discussion. Integration platforms and iPaaS products solved real problems, but the architectural mistake was allowing the product to become the architecture, effectively making all integration depend on one central platform.

The same pattern is emerging again around agent orchestration. Workflow execution, tool invocation, authentication, state, scheduling, retries, audit, observability, policy and human approval are all legitimate needs, but most are familiar software and integration capabilities. The genuinely new part is that an LLM can decide dynamically what to do next, and multiple autonomous runtimes can collaborate. That creates a need for orchestration capabilities; it does not automatically create a need for a new enterprise platform category.

The harness is the Agent Runtime

A harness gives an AI model the ability to do useful work by combining instructions, skills, tools, context, permissions, execution semantics and guardrails. Increasingly, harnesses also provide scheduling, state, evaluation and observability. In practical terms, that is already an Agent Runtime.

It might be Codex, another local runtime, a cloud-hosted service, a scientific runtime or a custom application. There is no architectural reason why all of these must sit beneath one central Agent Orchestrator. The runtime is replaceable; the enterprise capabilities it consumes should be enduring.

Great APIs are the architecture

The durable enterprise asset is the set of business and technical capabilities exposed through stable service boundaries. Applied to AI, the implication is simple: if a capability can be securely invoked through a governed API, any suitable harness can orchestrate it.

The enterprise standard can therefore remain thin:

  • standard web APIs, predominantly REST where appropriate

  • OpenAPI or equivalent machine-readable contracts

  • OAuth/OIDC authentication and authorization

  • clear scopes and least privilege

  • stable versioned contracts

  • consistent auditability and policy enforcement

If business systems, data services and document workflows expose capabilities this way, a suitably capable and authorized harness can use them. A local Codex runtime executing skills on a schedule can orchestrate work. So can a cloud service, a domain-specific runtime or a traditional application.

Discovery does not require a central orchestrator

A predictable objection is that, without a central Agent Orchestration Platform, a runtime needs another way to know which capabilities exist. That is a discovery problem, not an execution-centralization problem.

UDDI, WSDL, OData and OpenAPI all attempted to make services describable and discoverable. Their weakness was that a developer still had to understand the interface and wire it into an application. AI changes that equation because a capable runtime can interpret machine-readable descriptions and decide dynamically how to use the advertised capability.

As described in Old Wine, New Bottles: Why MCP Might Succeed Where UDDI and OData Failed, MCP can connect services to AI runtimes capable of interpreting discovered capabilities rather than merely cataloguing them.

The resulting pattern is straightforward: REST/OpenAPI describes what can be called, OAuth/OIDC governs who may call it, MCP or equivalent mechanisms can help machines discover it, and the harness decides how to compose and execute it. Registries and catalogs may still be useful, but they should describe capabilities rather than become mandatory execution paths.

Governance belongs at durable boundaries

This approach does not weaken governance; it moves governance to places that survive technology replacement. At the capability boundary, authentication, authorization, policy, auditing and data contracts should be enforced. At the runtime boundary, the harness should govern models, skills, tools, execution, observability and human approval.

That lets us change the harness, model provider or execution environment without redesigning enterprise capabilities.

The test

If we replace the agent orchestrator in five years, do we still possess the orchestration capability? If not, we have created a platform dependency rather than an enterprise capability.

Keep the capability when the platform changes

There is a legitimate need for orchestration: scheduling, tool invocation, state, security, policy, observability, evaluation, human approval and coordination. We should resist turning those needs into a mandatory enterprise Agent Orchestrator.

Enterprise capabilities should be exposed through thin, governed standards, while autonomous runtimes and harnesses remain free to discover and compose them wherever they run.

I’m not disputing the need for orchestration capabilities; I’m disputing the assumption that those capabilities imply an enterprise Agent Orchestrator platform.

Access to a Model Is Not a Working Capability

2026-09-16 /

“We don’t need ChatGPT Enterprise. We already have Azure Foundry.”

“I can run a model locally, so my tokens are free.”

Both statements mistake access to one component for possession of the complete capability. When I evaluate an AI alternative, I want to know what work it enables us to complete, at what quality, with how much intervention, and at what total cost.

Getting a model to run is an engineering achievement. Making it a dependable working environment is a much larger undertaking.

Microsoft describes Foundry as a platform for building AI applications and agents. That makes it a legitimate option for constructing capabilities. It does not, by itself, establish that those capabilities already exist for the people who need to use them. Someone still has to assemble, integrate, evaluate, operate and maintain the resulting product.

That distinction is central to the case for complete AI products. The value includes the work users can perform immediately and the engineering they do not have to commission first.

The model and its environment work together

I have argued that the harness matters increasingly: the tools, context management, execution environment, skills and controls surrounding the model. But this should not be interpreted as “the model no longer matters.”

Models differ in their ability to plan, handle ambiguity, use tools and recover from mistakes. Training can explicitly develop these abilities. OpenAI’s Codex launch report describes reinforcement learning on real coding tasks across environments, including learning to run tests iteratively.

The model and its working environment therefore cannot be treated as entirely independent components. Reproducing a tool interface does not automatically reproduce the learned behaviour needed to use it effectively.

Research supports the importance of that interaction. SWE-agent showed that purpose-built interfaces improved agents’ ability to navigate repositories, edit code and execute tests.

In my own work, Codex and Claude Code have been substantially more effective than Copilot App with an arbitrarily selected model. That is my experience, not a universal benchmark. It is nevertheless why I assess the complete working system rather than assume that a model catalogue establishes equivalence.

Smaller models belong in the architecture

I already advocate using powerful models to define a solution and smaller models to implement clearly specified work.

In one of my own implementation experiments, a local model spent approximately an hour without producing a usable implementation. After a frontier model clarified the representation, algorithm and initial test sequence, the local model produced a working implementation. Tests and an independent reference comparison passed, although review still identified two small contract deviations.

The useful result was a division of labour. Frontier reasoning established direction; local execution performed much of the implementation.

Recent research describes a similar mechanism. The preprint Better Harnesses, Smaller Models found that adapting harnesses improved 16 of 21 task–model combinations, with seven closing the performance gap. Adaptation worked best for repetitive workflows and models with sufficient underlying capability.

Even Small Language Models are the Future of Agentic AI, a position paper strongly advocating smaller models, centres its argument on specialised, repetitive tasks and proposes heterogeneous systems where broader capabilities are required.

This is consistent with my approach: resolve ambiguity, capture decisions in durable artifacts, and delegate well-defined execution. It does not establish that every smaller model can independently perform the reasoning that made the delegation possible.

Local tokens still have a cost

Local inference can be economically attractive. Removing the provider’s token bill, however, leaves hardware, electricity, operation, integration and maintenance. It also leaves the time spent waiting, supervising, correcting and retrying.

Those costs should be measured on both sides. Hosted products also have limits, require review and can fail.

The relevant comparison is total cost per successfully completed and accepted task. AI Agents That Matter makes the underlying evaluation argument: accuracy and cost must be considered together, and model benchmarks should not be confused with evidence that an agent suits a particular application.

A cheap unsuccessful attempt is still an unsuccessful attempt. A more expensive system can be better value if it reliably returns useful capacity to its users.

Replaceability does not establish equivalence

This is a counterpoint to the previous pattern. Designing a system so that its model can be replaced does not establish that another model will perform the same work successfully.

My model-replaceability pattern argues that business rules, trusted data, workflows and evaluation criteria should remain under our control. We should be able to change the reasoning engine without surrendering the application’s intended behaviour.

Replaceability still requires a sufficiently capable replacement. It does not imply that every model, harness or product is equivalent. The mistake is treating the ability to swap a component as evidence that we have replaced the capability of the complete system.

I am open to local models, open weights, alternative vendors and systems built on Foundry. The decision should follow representative work: compare accepted results, elapsed time, human intervention and the full cost of providing the capability.

I’m open to replacing the vendor. Show me that we can replace the capability—and what it costs to do so.

Pattern: Make Frontier Models Replaceable

2026-09-16 /

Making language models pluggable is useful, but it does not make an AI application independent of the model behind it.

A system may support several providers while still relying heavily on the behavior of one particular frontier model. When prompts carry implicit business rules, priorities and workflow decisions, the API can be replaceable while the business solution remains tightly coupled to a model.

This pattern applies primarily to business applications built on general-purpose frontier models. Specialized scientific models can be different: the model itself may embody a unique domain capability.

Treat the model as a replaceable reasoning engine

The durable business capability should live in the surrounding system: explicit business rules, authoritative data, tools, workflows, interface contracts, guardrails, evaluation criteria and deterministic processing.

The model reasons within those boundaries. It should not have to invent the boundaries each time it runs.

Consider an application that assesses requests for a refund. A model might interpret a customer’s explanation or identify missing information. Eligibility rules, approval limits and the steps required to issue a refund should be explicit. Replacing the model should not silently change the refund policy.

Use model upgrades as a diagnostic

Ask what happens if today’s model is replaced with a materially better one.

Better reasoning, instruction following, robustness and language quality are welcome. A better model may also handle cases that the previous model could not. Those improvements do not, by themselves, indicate an architectural problem.

The useful question is what changed. Does the system apply the same policy more reliably, or does it start making different policy choices? Does it understand difficult requests better, or does it change which requests deserve priority? Does it follow the workflow more accurately, or invent a different workflow?

Changes in business decisions, priorities or required steps are a reason to investigate hidden model dependence. An upgrade can expose how much application behavior was implicit in the prompt.

Recognize the prompt as hidden architecture

During prototyping, it is tempting to put everything into a prompt: how to interpret situations, what matters, which decisions to make, how to handle exceptions and what actions should follow.

This is fast. Over time, however, it can make business logic difficult to locate, test and govern. Model upgrades then become changes to application behavior, even when nobody intended to change the application.

The model has become both a reasoning engine and an implicit part of the application’s architecture.

Make the dependency explicit

  1. Specify business behavior. Define policies, priorities, decision rights and exception paths so that they can be reviewed independently of a model’s answers.
  2. Move stable logic outside inference. Use ordinary software for calculations, validation and rules that have a determinate answer.
  3. Ground reasoning in authoritative data. Give the model access to the relevant facts rather than relying on its general knowledge to supply business context.
  4. Put model calls behind clear contracts. Define inputs, expected outputs, validation and failure handling. Enforce permissions in the surrounding system.
  5. Keep prompts focused on the reasoning task. Make any policy instructions explicit and testable, and avoid relying on the model to fill gaps in the workflow.
  6. Evaluate across multiple capable models. Test important scenarios, including exceptions, and distinguish improvements in reasoning from changes in intended business behavior.

The aim is substantially stable business behavior when the reasoning engine changes. That still requires evaluation: a common interface cannot guarantee equivalent behavior across models.

Design for better models without depending on them

This pattern follows two broader engineering principles: use AI where ambiguity requires interpretation, and compose the application through explicit software contracts and workflows.

Those principles help determine where AI belongs. Replaceability asks how much the solution should depend on the particular model doing the reasoning.

Make the model easy to swap, but also make it possible to explain what must remain true after the swap. A better model should improve the system’s ability to perform its intended work. It should not be the first place where the intended work becomes defined.

Cheap Code Makes Software Engineering More Important

2026-09-16 /

At vibe coding meetups, I keep encountering the same excitement: people who have never developed software are suddenly building applications. Screens appear. Buttons work. Data gets saved. Something that previously required a development team becomes possible in an afternoon.

That is a remarkable capability. It also makes it remarkably easy to underestimate what remains.

A working application is the visible part of an iceberg. Below the waterline sit authorization boundaries, data integrity, concurrency, failure recovery, observability, dependency management and the ability to change the system safely.

These concerns rarely feature in the first demonstration. They become painfully visible when people start depending on the software.

My concern is that organizations are mistaking the ability to produce that demonstration for the ability to engineer and maintain the system beneath it. People gain production responsibility before they have acquired the judgment needed to carry it.

Now, as coding agents drift, contradict earlier decisions and struggle with growing codebases, specifications are being rediscovered. Write down what you want. Ask structured questions. Decompose the work. Define acceptance criteria. Give the agent clearer boundaries.

I welcome those practices. What worries me is the belief that following a specification-driven development method is sufficient to produce good software.

A method can help uncover missing requirements. It cannot guarantee that the questions cover what matters, that the answers are sound, or that the resulting design is appropriate. Someone still needs to recognize the omissions and challenge the assumptions.

An inexperienced builder may describe the visible behavior in considerable detail while leaving everything below the waterline unresolved. The resulting document can look comprehensive. The agent can implement it faithfully. The tests can pass.

The system can still be insecure, fragile and expensive to maintain.

That is the false confidence I worry about: believing that because we have followed a method, we have specified the whole system.

Dex Horthy makes a related argument in Harness Engineering Is Not Enough. He describes the difficulty of maintaining codebase quality when agents optimize for completing individual tasks. His response is to bring human steering, program design and code review firmly back into the process.

He also acknowledges that he cannot prove his broader claim about models’ long-term maintainability limitations. That distinction matters. His experience describes a credible failure mode; it does not establish that every AI-assisted codebase will deteriorate.

There is nevertheless evidence supporting the concern.

The public summary of Gartner’s Predicts 2026 report identifies generated-code quality risks and calls for architecture-first validation and explicit boundaries between human and AI responsibilities. That is analyst guidance, rather than experimental proof, but it places architectural discipline squarely in the response.

McKinsey’s developer study found productivity gains and marginally improved code quality when developers actively worked with the tools. It also identified human expertise as crucial for finding errors, supplying organizational context and navigating complex requirements. The developers’ judgment was part of the successful result.

The confidence problem has empirical support too. In Do Users Write More Insecure Code with AI Assistants?, researchers found that participants using an AI assistant produced less secure code while being more likely to believe their code was secure. The study used an older model, so it cannot establish today’s vulnerability rate. It does demonstrate how assistance and misplaced confidence can coexist.

The maintenance evidence is more mixed. A study involving 151 participants, overwhelmingly professional developers, found no significant downstream maintainability degradation within its experimental scope. That limits any blanket claim that AI necessarily makes software harder to maintain. It also leaves open my concern about inexperienced builders taking production responsibility without comparable engineering support.

In The Bottleneck Moved, I argued that cheaper implementation shifts the constraint toward ambiguity, architectural clarity, decomposition and validation. Faster code generation also lets us accumulate the consequences of unresolved decisions faster.

That changes what we should ask experienced software people to do.

Bring them into the work while the solution is being shaped. Have them establish the boundaries, examine the data model, challenge assumptions and decide how correctness will be demonstrated. Let AI accelerate implementation inside those decisions. Keep engineers accountable for reviewing the result and making it operable.

This does not require every prototype to undergo a full production process. It requires an honest distinction between exploring an idea and accepting responsibility for a running system.

Nor is a degree or job title sufficient. The capability we need is the ability to reason about a system beyond its visible behavior, recognize the limits of our understanding and investigate what we have missed.

My prediction is that we are building toward a wave of maintenance debt and security remediation as today’s impressive demonstrations become tomorrow’s business-critical systems. Much of the bill will arrive after the original excitement has faded, landing with people who had no part in the decisions that created it.

Perhaps, by the time that wave arrives, AI will have developed the architectural judgment needed to repair what we are producing today. I hope so. But relying on tomorrow’s AI to rescue today’s engineering decisions seems an extraordinary way to run software development.

Hosting Location ≠ Jurisdictional Independence

2026-09-14 /

Executive Summary

Running a workload in an EU data center is not the same as operating independently of non-EU jurisdictions. For sovereignty, the important questions are not only where the infrastructure is physically located, but also who owns, controls and operates it, which legal regimes apply to the provider, and whether a third-country government could materially affect continued access.

If AI becomes critical enterprise infrastructure, jurisdictional resilience should be treated as a business-continuity concern rather than merely as a data-residency or procurement issue.

Hosting Location and Jurisdiction Are Different Things

Cloud providers increasingly offer products described as EU sovereign, European sovereign or sovereign cloud. These offerings can provide real controls, including EU data residency, locally operated infrastructure, restricted administrative access, EU-based personnel, encryption and key-management controls, and contractual commitments around support and operations.

Those controls matter, but they do not by themselves establish jurisdictional independence. A service can be physically hosted and operationally isolated in Europe while the ultimate provider, parent company, software supply chain or control structure remains subject to another jurisdiction.

The practical sovereignty test is therefore whether geopolitical, legal or trade changes in a third country could materially affect access to the service.

Europe Is Beginning to Distinguish Levels of Sovereignty

The European Commission’s current Cloud and AI Development Act framing is useful because it separates physical location from deeper forms of sovereignty. The proposed framework describes four levels:

  1. Level 1 — data is processed and stored in infrastructure located in the EU.

  2. Level 2 — providers must demonstrate independence from third countries and transparency over their software supply chain.

  3. Level 3 — providers must be owned and controlled from the EU, with additional requirements.

  4. Level 4 — providers provide full transparency and control over the software supply chain and no interference from a third country.

Source: European Commission — Cloud and AI Development Act

The important point is that physical location is only one dimension. Independence, ownership, operational control and freedom from third-country interference are separate considerations.

Data Residency Is Not Sovereignty

Data residency answers where data is stored and processed. Sovereignty is broader: who can access and operate the service, which legal regimes can compel the provider, who controls the software and infrastructure, and whether the service can continue if geopolitical relationships deteriorate.

European data-protection guidance following the Schrems II judgment already reflects this distinction by requiring organizations to consider whether laws and practices in a third country could prevent a provider from complying with European safeguards.

Source: European Commission — Standard Contractual Clauses and Schrems II

The same reasoning is relevant to strategic technology dependency even when the immediate issue is not personal-data transfer.

Sovereignty Is Also About Continuity

For organizations, the more important issue may be continuity of strategic capability rather than compliance alone. If AI becomes embedded in research, supply chain, commercial operations, software engineering and knowledge work, dependence on a single geopolitical technology ecosystem becomes a business risk.

The relevant scenario is not necessarily that a provider voluntarily chooses to stop serving us. Regulation, sanctions, export controls, national-security measures or broader geopolitical events can constrain what a provider is legally permitted to deliver. In that situation, contractual assurances about an EU-hosted region are only as durable as the legal and operational independence behind them.

This should therefore be framed as resilience rather than vendor distrust. The issue is whether strategically important AI capabilities should depend entirely on continued permission from one jurisdiction.

Architectural Implication

The answer is not to abandon US hyperscalers or frontier-model providers. We should use the best services available where they create value, while ensuring that strategically important AI capabilities have a credible path to alternative jurisdictions and providers if needed.

That implies designing for:

  • portable workloads

  • model independence where practical

  • open or replaceable interfaces

  • data portability

  • infrastructure portability

  • open models as a credible fallback

  • access to EU-controlled compute and inference

  • avoidance of dependencies that cannot be reproduced outside a single provider ecosystem

This is consistent with the EU Data Act, which pushes cloud providers toward interoperability, switching and open interfaces so customers can move between providers without losing data or functionality.

Sources:

Sovereign AI Should Be an Option, Not Necessarily the Default

This is not an argument that every workload should immediately run on European-owned infrastructure. It is an argument for maintaining a viable option.

If strong open models continue to close the capability gap with proprietary frontier models for many enterprise workloads, then a sovereign execution path becomes increasingly practical. That path could involve European-owned GPU infrastructure, European inference providers, open-weight models, managed or self-hosted open-model inference, European model providers, and workloads capable of moving between US, EU and other regional ecosystems.

The strategic value is that organizations would not need to create that capability from scratch after a crisis has already begun.

A Useful Test

For any service described as sovereign, ask what legal and operational mechanisms would prevent a government outside the EU from suspending, restricting or otherwise affecting the service through the ultimate provider. If the answer is only that the servers are located in Europe, then the service provides data residency; that alone does not establish jurisdictional independence.

Conclusion

Sovereignty is a spectrum, not a hosting-region label. Physical location, operational separation, personnel and key control all matter, but so do ownership, jurisdiction, software supply-chain control and the ability to operate independently of third-country intervention.

For strategic AI infrastructure, the objective should be to avoid single-jurisdiction dependency and preserve a credible path to continue operating critical AI capabilities under European legal and operational control if circumstances require it.

Hosting location ≠ jurisdictional independence.

Peter Birkholm-Buch
Søvej 6
2665 Vallensbæk Strand
Mobil 26560203
Email peterbb@gmail.com
CVR: 34513287
Bank: Nordea
Konto: 5510-0747692815
SWIFT: NDEADKKK
IBAN: DK3620000747692815
Bitcoin: 1NiBdnmFGhZN2hpM5BRNHqCSD8wpyYNvZf

Follow me on Twitter

See my profile on LinkedIn

© 2026 Peter Birkholm-Buch

Theme by Anders Noren — Up ↑