A field guide for anyone shipping agentic AI into a regulated lending or servicing environment — why the model is the smallest part of the system, and what to engineer around it instead.
The Skill Has Moved Again
A few years ago, the highest-leverage AI skill was prompt engineering — the exact wording of an instruction genuinely changed output quality, because models were rigid and the input carried all the weight.
Then models got better, and the bottleneck shifted to context engineering — curating what the model could see at inference time: retrieved documents, conversation history, memory, tool outputs.
We're now in a third era. Models can write their own prompts and pull their own context through tool calls. Input is no longer the scarce resource. What's scarce now is the design of the loop the agent runs inside — when it checks its own work, when it decides it's done, and what happens the moment a step fails.
That discipline is loop engineering, and underneath it sits a layer most teams never name until it breaks their system in production: harness engineering — the deterministic scaffolding wrapped around the non-deterministic model.
As the diagram above shows, a production agent isn't just a reasoning engine. It's a reasoning engine sitting inside four concentric rings — a loop with real exit conditions, a harness of deterministic controls, a verification gate checked against policy, and observability that traces every step. Every input on the left (documents, enterprise data, APIs, human experts) and every output on the right (policies, security, human escalation, audit) flows through those rings. Reliability doesn't come from a smarter model in the center. It comes from the engineered system around it.
The Loop, Precisely
Strip away the hype and every agent runs the same primitive — the classic ReAct cycle: the model reasons, chooses an action, the harness executes it, an observation comes back, it's appended to context, and the model reasons again.
The part almost nobody engineers deliberately is the stopping condition. Without one, agents spin, re-reason, and burn tokens on tasks they can't complete — or they quit after one shallow pass and call it done. Production systems need several stopping signals layered together: an explicit "done" signal, a hard iteration cap, a cost/token budget, and a verifier that terminates the loop on a pass. "The model produced an answer" is never a valid exit condition on its own.
The economics matter too. Every iteration is a full model call — an agent that takes ten steps to do a two-step task isn't just slow, it's ten times the inference bill and ten times the surface area for something to go wrong.
A Real Incident: The Covenant That Slipped Through
Here's how this plays out with real stakes. Picture a covenant-monitoring agent inside a wholesale lending portfolio: it reads incoming borrower financials, checks them against covenant thresholds — leverage, debt service coverage, minimum liquidity — and flags anything in breach so a relationship manager can act before it becomes a credit event.
The pilot goes well. It ships. Three months later, a borrower's debt service coverage ratio (DSCR) quietly slips below the covenant floor for two consecutive quarters. Nobody flags it. The relationship manager finds out the way everyone eventually does — the borrower calls asking for a waiver.
Nobody wrote bad code, and the model was never "wrong" in any single response you could point to. The data feed carrying the borrower's latest financials timed out; the agent had no instruction for "the lookup failed," so it reasoned over whatever was already in context — last quarter's numbers — and confidently marked the case "Reviewed — No Action." The model reasoned correctly. It just reasoned from incomplete evidence, because nothing in the system told it the evidence was incomplete.
The diagram below walks the entire arc in one view: the production failure as it actually happened on the left, the engineered workflow that would have caught it in the middle, and the controlled outcome on the right.
Notice what changes in the middle column. The harness intercepts the timeout instead of letting it pass silently. A retry runs; when it fails again, the case is explicitly marked data unavailable and routed to a human review queue rather than let the loop proceed on stale numbers. Once the current financials are retrieved, the DSCR is recalculated — 1.04x — and checked against the actual covenant rule, ≥ 1.10x, by a deterministic verifier gate. That's a fail, so the case is escalated the same day, with the breach details and supporting evidence attached, instead of surfacing three months later as a borrower's phone call.
Nothing about the model changed between the left column and the right. The engineering around it did.
Harness Engineering: The Architecture Underneath the Loop
The seductive part of agentic AI is the non-determinism. What actually decides whether the system survives contact with real traffic is almost entirely deterministic — retries, timeouts, schema validation, authentication, rate limits, and a verifier gate that gets the final word before anything leaves the loop.
The diagram below is the full production architecture: a request enters, the agent loop (plan → act → observe → decide) iterates inside a harness of deterministic controls, calls out to tools and data, and every result — success or failure — passes through a verifier before the loop is allowed to exit.
A few details worth calling out explicitly:
"LLM produced an answer" is not an exit condition. The verifier — or an explicit escalation — is the only valid way out of the loop. This single rule is what prevents the "reviewed, no action" failure from the incident above.
The verifier checks against real, named thresholds — DSCR ≥ 1.10x, leverage ≤ 4.0x, liquidity above a floor, required fields present, data freshness valid. These aren't AI judgments; they're policy rules a deterministic gate can check every single time, without getting tired or distracted.
Failure has exactly two destinations: retry (with backoff and iteration limits) or escalate (to a human review queue) — never silent continuation on bad data.
Every case closes through the same two paths: pass → close + log, or fail → escalate, and both paths write a trace. That's what turns a black box into something a model-risk reviewer or examiner can actually review.
This reframes evaluation, too. Grading "was this one reply good" is necessary but nowhere near sufficient — the real question is whether the system degrades gracefully under a tool failure, a malformed response, or an edge case it hasn't seen before. You're grading a system under stress, not a sentence.
Introducing BMI — Bare Minimal Intelligence
Given all of the above, the practical question becomes: how do you build any of this without collapsing into an unmaintainable web of agents, memory stores, and orchestration layers before you've even confirmed the basic loop works?
BMI — Bare Minimal Intelligence — is the answer: add exactly one capability layer at a time, and only once the current layer has a demonstrated, evidence-backed need for the next one. Nothing gets added because it's trending.
Two layers are flagged in the diagram as "often skipped, critical in production" — Layer 2 (Continuous Evaluation) and Layer 4 (Verification + Escalation) — and that's not a coincidence. They're exactly the two layers that would have caught the covenant incident above: evaluation would have surfaced the stale-data pattern in week one instead of month three, and the verifier would have caught the breach before it ever reached a dashboard. They're also the two layers that never show up in a demo, which is precisely why they're the two most commonly cut to hit a launch date.
The discipline underneath BMI is simple to state and genuinely hard to follow: build the minimum required, measure in production, and earn the next capability with evidence — not with momentum.
Mapping It to a Production Runtime
None of this is theoretical — it maps cleanly onto a real, secure, observable agent runtime. The diagram below shows the same request → loop → harness → tools/data → state & memory → verifier pipeline, now paired with the four supporting planes that make it production-grade: harness orchestration, identity and authentication, observability, and continuous evaluation — sitting on top of the foundational pillars of security, reliability, scalability, cost control, and governance.
A few mappings worth calling out for teams building this on AWS:
Harness orchestration (workflow orchestration, step management, input/output guardrails) is where stopping conditions and policy guardrails actually live — the natural home for a Step Functions–style state machine wrapping Bedrock model calls.
Identity (inbound/outbound authentication, credential vending, tenant isolation) is what keeps a covenant-monitoring agent scoped to only the accounts and data it's authorized to touch — non-negotiable in a regulated lending environment.
Observability (distributed tracing, structured logs, correlated events, SLIs/SLOs) is what turned the two-week covenant post-mortem into a five-minute one in the fixed version of the incident.
Evaluations & optimization (built-in and custom evaluators, A/B testing, versioning, canary/rollback) is the deterministic feedback loop that catches drift and regressions before they reach a real portfolio.
The four foundational pillars along the bottom — security, reliability, scalability, cost control, governance — aren't a separate initiative from the agent itself. They're what "harness engineering" actually means once you draw the whole system out.
Closing: What to Actually Do
Stop optimizing a single component in isolation. The classifier, the reply generator, the retriever — none of it matters if the loop stalls right after a tool call fails silently. Optimize the loop, because every node depends on the one before it.
Design your stopping conditions deliberately. "The model produced a response" is never the exit condition — a verifier pass, an explicit escalation, an iteration cap, or a cost budget are.
Take system-level evaluation as seriously as model evaluation. Trace full runs end to end, not isolated completions — this is the layer most teams skip, and the one that would have caught the incident above in week one.
Put cheap, reliable verifiers inside the loop; put humans exactly where verification is genuinely expensive. A covenant threshold is a rule a machine can check every time. Whether a waiver request is reasonable is a judgment call for a person.
Build with BMI. Ship the bare minimal system end to end first, and add each layer — tool use, evaluation, memory, verification, human-in-the-loop — only when there's a demonstrated, observed need for it.
On AWS, let the harness own the loop's control flow, a verifier gate own the deterministic policy checks, and full-stack observability own the evidence trail — so when something breaks (and it will), you can find exactly which layer failed, the same day, not next quarter.
The uncomfortable finding underneath all of this: the model very rarely fails in the dramatic, headline way people picture. It fails quietly, through the plumbing — a stale lookup, a skipped check, an unlogged decision. That's not a reason to slow down agentic adoption in lending. It's the reason the engineering discipline around the loop matters at least as much as the model choice itself.
