AI Model Harness Development in Singapore

Ask an enterprise team in Singapore what they bought when they bought AI and most will name a model. The more useful answer is the software wrapped around that model. The industry has settled on a name for it, the harness, and AI model harness development has quietly become the part of the stack that decides whether a project reaches daily use or stalls in a proof of concept.

The framing comes from the Wall Street Journal's CIO Journal, which described the harness as the system wrapped around the brains. The models are the brains. A harness is what lets a rider steer a horse, and it is what lets a business steer a model. The analogy holds in a way that matters commercially: the horse is rented, the harness is yours.

What an AI Model Harness Actually Is

A harness is the software layer between a language model and your business. It decides which model answers a request, what context that model receives, which tools and systems it may call, what it is allowed to do with the result, and what gets written to an audit log. The model reasons. The harness supplies the world it reasons about.

The idea became prominent alongside reasoning models. On its own, a reasoning model produces text. Paired with a capable harness, the same model connects to real systems, executes code, and manages multi-step workflows. That pairing is the difference between a chat window and something that closes a loan file, reconciles a ledger, or drafts a regulatory submission.

The model is the part you can swap. The harness is the part that carries your process, your data, and your controls.

Harness Engineering Gives You Back Control

The commercial argument for building your own harness is straightforward. When workflows live inside a vendor's product, the workflows move when the vendor moves. Pricing changes, deprecations, rate limits, and roadmap decisions all land directly on your operations. Building the software around the model, a practice CIO Journal calls harness engineering, decouples your workflows from any single provider.

If you bring that harness in-house and control it, you are baking in a lot more business resilience.

That resilience is not theoretical. Model capability is moving fast enough that the best option for a given task changes every few months. Teams with their own harness treat that as a configuration change. Teams without one treat it as a migration.

Why AI Harness Development in Singapore Looks Different

Singapore adds a second reason to build rather than rent, and it is a regulatory one. Banks, insurers, capital markets firms, and public agencies here operate under supervisory expectations that assume you can explain and evidence how an automated decision was made.

The MAS FEAT principles set expectations around fairness, ethics, accountability and transparency for firms using AI in financial services, and the Veritas work that followed turned those principles into assessment methodology. On the national side, the IMDA and PDPC Model AI Governance Framework for Generative AI, together with the AI Verify testing toolkit, has become the reference point most boards ask about. Layered on top is the PDPA, which governs the personal data your harness will inevitably route into a prompt.

None of those frameworks require you to own your harness. What they require is evidence, and evidence is easier to produce when the logging, the model routing decisions, the retrieved context, and the tool calls all sit in systems you operate. For a regulated firm, the harness is where compliance is actually implemented. Prompts and context for a credit decision or a suspicious transaction review are business records, and many Singapore institutions would rather those records never leave infrastructure they control.

This is why AI harness development in Singapore tends to start in the most regulated corners of the business. We see it most often in banking, capital markets, and government, where the harness is scoped as core infrastructure rather than as a feature of one application.

Build Your Own or Adopt a Vendor Harness

The build case is not universal. Anthropic and OpenAI both ship harnesses for enterprise customers, and they are good. Bristol Myers Squibb standardised on Anthropic's Claude as its harness specifically to avoid rebuilding basic infrastructure tooling, a decision its chief digital and technology officer, Greg Meyers, has described publicly. For a company whose differentiation is molecules rather than middleware, that is the right call.

Three questions usually settle it.

• Does the workflow carry data or decisions that a regulator will ask you to evidence? If yes, the control argument for building is strong.

• Is the workflow a durable business process or a productivity convenience? Processes justify infrastructure. Conveniences rarely do.

• Would switching providers next year cost you weeks or months? If months, you are already paying for a harness. You are just paying for someone else's.

The answer is often a mix. Adopt a vendor harness for general knowledge work, and build your own for the handful of workflows that sit close to regulated data. The two coexist as long as you decide deliberately which is which.

The Router Is Where Token Costs Are Won

One component earns its keep faster than any other: the router. A router chooses between a frontier model and a cheaper one on a per task basis, so a document classification does not pay frontier pricing and a complex reasoning task is not starved by a small model. As AI usage moves from pilots to production volumes, routing is the single most effective control on token spend.

A good router is more than a cost switch. It is also a resilience mechanism, because it gives you a tested fallback path when a provider degrades, and a policy mechanism, because it can keep a class of sensitive requests on a specific model or a specific deployment region. Build the routing layer early, even if it only points at one model on day one.

Context Engineering Is the Part That Does Not Change

Moody's, a company with more than a century of history, built its own harness style tool called Research Assistant. It is an agent that works across Moody's own datasets and switches between models on the back end. The interesting part is not the chat interface. It is that a century of proprietary data was made available to a model under the company's own controls.

That is the durable lesson. The vocabulary keeps moving, from prompt engineering to context engineering to harness engineering, but the underlying need is constant: supplying language models with the right context at the right moment. Whatever the next term is, the work is the same work.

What does not change is the ability to supply language models with the right context.

What Goes Into a Production Harness

When we scope a harness for a client, the build reduces to a fairly consistent set of components.

• Model gateway and router: one interface for every provider, with per task model selection, fallbacks, and cost telemetry.

• Context and retrieval: the pipelines that assemble the right documents, records, and system state for each request.

• Tool layer: the typed, permissioned interface between the model and your real systems, from core banking to case management.

• Orchestration and state: durable multi-step workflows that survive retries, timeouts, and human approval steps.

• Evaluation: a regression suite of real cases so a model or prompt change can be measured before it ships.

• Guardrails and policy: input and output checks, data residency rules, and the human in the loop points a regulator will look for.

• Observability and audit: traces, prompt and context capture, and an immutable record of what the system did and why.

Most teams already have pieces of this scattered across applications. The value of naming it a harness is that it becomes one shared platform with an owner, rather than seven half implementations with none.

Where to Start

Start with one workflow that is well understood, data rich, and genuinely painful. Build the gateway, the router, the tool layer, and the audit trail for that workflow alone, and resist the pull to design a platform for problems you do not have yet. Instrument it properly from day one, because the evaluation suite you build for the first workflow is what makes the second one fast.

Then expand. The second workflow should reuse most of the harness and add a little to it. If it does not, the first build was an application rather than a platform, and it is worth correcting early. By the third or fourth workflow, the model your team started on will probably no longer be the model in production, and that is exactly the point.

We build harnesses for regulated organisations across Singapore and the region, from the routing and evaluation layer through to the audit trail. If you are weighing whether to build or adopt one, talk to us or start with Accelerate, our scoped kickstart for a first production workflow.