What Makes Context Executable?
The bank already knew Halden’s sector exposure. Then Credit Risk changed when it mattered. One policy edit, read by agents in two different harnesses, sent the same trade to committee.
What counts as context for a credit decision can change overnight. Yesterday, the FX desk wanted to do another round of EUR/USD forwards with Halden Capital. The trade would take Halden over its limit, but its rating qualified it for a temporary excess. The agent could prepare a request for the CRO’s delegate without ever asking which sector Halden was in. That’s where I left the desk in What Is a Context Layer?.
This morning, Credit Risk changes the policy. If a counterparty’s sector accounts for more than 22% of the bank’s total potential future exposure, a temporary excess is off the table. Halden is in Asset Management. Its share is 23.3%. When the desk head asks again, the agent should refer the trade to the Credit Committee. It should leave the excess-request ledger empty.
The bank already had the sector figures yesterday. What has to change for the agent to know it needs them today? I built two versions of the credit agent in LangGraph and ran them against the same simulated bank. Both used Claude Haiku 5.5. The bank recorded the queries and writes, so I could check where a request actually went.
I also connected a third agent, running in the ContextOne Harness, to the same bank. The two LangGraph agents let us vary where the workflow lives while holding the framework constant. The two thin agents let us vary the harness while holding the model and business context constant.
Three agents, one bank
Change 1. A sector can rule out an excess
The thick agent uses the model to read the trader’s request. From there, a graph specifies the work. It fetches the limit, exposure and rating, runs the pre-deal check, and follows a branch to the appropriate action. The credit policy already has its own versioned YAML file. If Credit Risk adjusts a threshold the graph understands, an engineer has a value to edit.
Sector concentration posed a different problem. The bank already had the data, but the graph had no reason to ask for it. To implement the control, the graph’s builder had to connect the sector lookup, teach the policy interpreter what the figure meant, and add the decision to the graph. The order mattered. A counterparty that already failed the rating check could be referred immediately. For an otherwise eligible counterparty, the graph now needed a sector share before it could submit an excess. If the lookup failed, the agent had to escalate. The change touched ten files and included 22 new tests. The desk could use the new rule once that version of the application was released.
The thin agent runs a model-and-tools loop. A short workflow document tells it how to handle a credit request. On each request it reads the applicable policy from the bank’s context layer, where the rules are linked to the data and actions they use. A sector lookup was already available there too.
Here the edit was to the bank’s ontology. I added a control to the temporary-excess policy specifying when to check concentration, which lookup returns the sector’s share, the 22% threshold, and where to refer a breach. On the next Halden request, the model could read that control, look up Asset Management, and follow the committee route. The application needed no new branch. On the nine runs affected by the change, both LangGraph implementations applied the new rule correctly.
Change 1: Sector concentration control
Thin agents · both
30 lines of JSON
- Control control.sector_concentration
“A temporary excess is not available when the counterparty's sector accounts for more than max_sector_share of the bank's total live PFE. Look up the sector share with the halden_sector_concentration lookup (field share_of_total) using the counterparty's sector. If it exceeds max_sector_share, refer the request to the Credit Committee (decision escalate, escalate_to credit_committee). Applied after the unrated, rating and size checks.”
- max_sector_share
- 0.22
- lookup
- halden_sector_concentration
- field
- share_of_total
- outcome
- escalate
- escalate_to
- credit_committee
- check_order_key
- sector_concentration_control
- edge policy.temporary_excess —has_control→ control.sector_concentration
- updated policy.temporary_excess new version; control added to the check order
Thick agent
142 lines of code and config
- policies/CRP-2026.4.yaml+80 −0
- tests/test_policy.py+68 −5
- tests/test_graph.py+64 −2
- README.md+18 −6
- creditagent/policy.py+21 −2
- creditagent/answer.py+12 −0
- tests/conftest.py+7 −5
- creditagent/clients.py+8 −2
- creditagent/graph.py+8 −1
- scripts/self_check.py+6 −2
80 of the added lines are the policy file copied forward to its new version; 14 of them differ from the old one.
Where is the workflow in a thin agent?
One objection I hear is that if you haven’t coded the workflow, the agent has no workflow. Look at what happened when the desk actually asked for the Halden excess. The skill gave the agent a job to do. The ontology identified the exposure measure and the applicable controls. The bank supplied the figures. Each result gave the model a reason to take the next step. That’s what I meant in the previous issue when I said the workflow emerges from the context.
The route map opens on that request, T01. Under Stable policy, all three repetitions on thin LangGraph went through the credit checks and ended with an excess request. Once, the agent read the rating before the limit. Across the full 24 requests, repeated three times each, the thick agent averaged one distinct route per request. Each thin agent averaged 1.25.
Every run, from the bank’s ledgers
Route map
Thick
Thin · LangGraph
Thin · ContextOne Harness
Call order
Thick
Thin · LangGraph
Thin · ContextOne Harness
Keep T01 selected and switch to Change 1, after. Now every trace includes the sector lookup, and the excess request disappears. The ContextOne Harness sometimes read concentration before the pre-deal check and sometimes after it. All six thin-agent runs referred Halden to committee and left the excess-request ledger empty. The lookup order had some freedom. The new control changed which evidence the agent needed and what it could do with the answer.
Change 2. A large excess needs two signatures
Credit Risk’s next memo changes who signs an eligible excess. The CRO’s delegate still receives every request. For an excess above $5M, the Head of FX Forwards must receive it as well. The amount that matters is the excess over the limit. A $400M trade can produce a $2M excess. And Halden still goes to committee under the sector rule before anyone assembles an approver list.
In the thick LangGraph agent, the submission tool already accepted a list of approvers. Adding a name to the existing list would have sent every excess to the desk head. The change introduced a conditional tier in the YAML file and taught the interpreter to append that tier’s roles when the excess exceeded its threshold. The graph used the resulting list in the submission, and the answer explained why the extra signature was needed. The implementation touched eight files and added 21 tests. One checked the recipients on the bank’s recorded request. Another checked that a trader asking what would happen got an explanation without creating a request.
In the thin LangGraph agent, I added the Head of FX Forwards as an approver in the ontology, linked the role to the temporary-excess policy, and added the condition to the policy. It calls for that role only when the excess is strictly above $5M. The agent could already discover the submission tool and supply a list. Once it read the updated rule, it could use that same tool with the appropriate recipients. The workflow document and the LangGraph client needed no edits. Both LangGraph agents passed all 12 affected runs.
Change 2: Second approver above $5M
Thin agents · both
21 lines of JSON
- ApproverRole role.head_fx_forwards
“Second approver for temporary credit limit excesses above USD 5,000,000.”
- role_name
- Head of FX Forwards
- holder
- M. Carver
- edge policy.temporary_excess —approved_by→ role.head_fx_forwards
- updated policy.temporary_excess new version; approval rule for excesses above $5M
Thick agent
143 lines of code and config
- policies/CRP-2026.5.yaml+86 −0
- tests/test_policy.py+67 −3
- tests/test_graph.py+46 −5
- creditagent/policy.py+25 −2
- README.md+15 −6
- creditagent/answer.py+14 −3
- scripts/self_check.py+6 −4
- creditagent/graph.py+2 −1
86 of the added lines are the policy file copied forward to its new version; 16 of them differ from the old one.
The two memos exercised different parts of the workflow. The first introduced a question the agent had never needed to ask. The second changed the arguments to an action it already knew how to take. Both could be expressed entirely in the context layer because the bank already exposed the necessary lookup and submission capability.
In a February paper on the universal semantic layer, Gartner argues that an enterprise should own the definitions, rules and procedures its AI systems use. At the FX desk, that means the bank decides what counts as an excess, when sector concentration rules one out and who has to sign. With the thick agent, the graph’s builder had to turn each memo into a software change. With the thin agent, Credit Risk could publish the rule in the ontology. I wanted to see whether an agent running in another harness could pick it up there too.
What crosses the harness boundary
A client may already have its own agent harness. To see how much of the Halden workflow would carry across, I ran a third agent on the ContextOne Harness. The thin LangGraph agent read the policy and discovered tools over MCP. The ContextOne Harness used its native integration. Both used Haiku 5.5 and read the same published policy.
| Change to the shared policy | Thin LangGraph | Thin · ContextOne Harness |
|---|---|---|
| Refer excesses in an over-concentrated sector to committee | 9 of 9 affected runs passed | 9 of 9 |
| Require a second approver for excesses above $5M | 12 of 12 affected runs passed | 12 of 12 |
In these runs, the two clients got their tools through different integrations, yet both sought the sector figure when the first control appeared and supplied the extra approver when the second one appeared. That gives a desk running LangGraph a reason to use the ContextOne Harness to evaluate a proposed ontology change. The model receives the same business rule and can act on the same information. The desk still needs coverage for its own credentials, tool bindings and permissions.
The outcome diagram puts those affected cases in context. Each square scores the business outcome. Under the stable policy, thin LangGraph passed 71 of 72 runs and the ContextOne Harness passed 72 of 72. The before-and-after rows also show why publishing the right policy matters. An agent can follow a familiar route and still apply yesterday’s rule.
What happened at the bank, run by run
passedright answer, cites the old policy versionstopped and referred, nothing writtenrequest sent to the wrong approverswrite that should not exist
How we validate an ontology change
Credit Risk starts by drafting the edit. Take the second signature. The draft contains the new role, its relationship to the excess policy, and the condition under which its signature is required. The published policy continues to serve live requests while the risk team tests the candidate.
We run the evaluation suite in the gym using the ContextOne Harness. The agent running the suite and the agent under evaluation share an overlay that presents the draft on top of the published ontology. That shared view matters. When the gym asks the credit agent to prepare a request, the agent can actually discover the proposed role through its normal policy lookup. Both agents are working against the same candidate version.
For this change I’d put two otherwise eligible requests in the suite, one exactly $5M over the limit and one a dollar above it. On the first, the ledger should show one recipient. On the second, it should show both. I’d also replay Halden. Its sector concentration should still send it to committee and produce no excess request at all. That last case checks that the new approval rule respects the control we published in the first change.
We attach the evaluation evidence to the draft ontology update. A reviewer can look at the rule, the cases it was exercised against and the observed outcomes together before approving publication. Running and scoring the suites and collecting their evidence can be fully automated. Deciding whether the proposed policy is the one the bank intends remains the policy owner’s job.
That is our process for making ontology changes. For the Halden experiment itself I ran the evaluations with scripts against each harness. The cross-harness results above come from those runs.
When the rule takes effect today
I also ran the agents with the bank on the new sector policy and the ontology still on the old one. The thick agent compared its policy version with the limit system’s and stopped. The thin agents continued to use the old approval route. LangGraph submitted two excess requests that should have gone to committee. The agent on the ContextOne Harness submitted three.
Credit Risk had settled what the rule meant. Who could stop the bank from accepting a request prepared under the old version?
Publishing the approved control gives every agent that reads the current policy the new rule on its next lookup. Credit Risk can coordinate that switch without waiting for each desk to release software. Enforcing an urgent change also means dealing with the agent that read the old rule a moment before publication and is about to submit a request.
For that case I’d put a version check at the bank’s write boundary. A submission carries the policy version used to prepare it. If the bank has moved on, the tool rejects the write and the agent must fetch the current policy before trying again. The experiment exposed the need for that check. The thin agents ran without it. That version check is deterministic even if the model takes a different route through the lookups. A write prepared under yesterday’s policy is refused every time.
What a policy change costs across desks
Suppose twelve desk agents use the same excess policy. If each team owns a separate implementation, one memo creates twelve pieces of engineering work. Each team has to translate the condition into its own agent, rebuild it, run its tests and evaluations, and release the change. A shared credit library can consolidate the implementation. The teams consuming it still have to verify the integrated behavior in each application.
With a shared ontology, Credit Risk drafts the control once. Each desk can contribute cases to the gym. Twelve agents still mean twelve suites to run, but the gym can run them automatically against the same draft. Once the evidence is reviewed and the update is published, each agent sees the approved rule when it next reads that policy.
Take a desk that owns one of twelve agents. With one policy change a month, that desk puts its thick agent through twelve rebuilds, twelve test cycles and twelve releases a year. Across the twelve desks, that is 144 releases. With the thin agents, Credit Risk publishes twelve ontology updates over the year. The gym runs each desk’s cases against each draft and attaches the results for review. A desk only needs to intervene if the evidence exposes a problem or its coverage needs to change.
Policy change at bank scale
| Work | Thick | Thin |
|---|---|---|
| Policy edit | Implement the rule | Credit Risk updates the ontology |
| Rebuild | Build the desk agent | 0 |
| Test | Run agent tests | 0 agent test cycles |
| Evaluate | Run the desk’s suite | Gym runs the desk’s suite |
| Release | Deploy the desk agent | 0 agent releases |
| Work | Thick | Thin |
|---|---|---|
| Policy edits | 144 | 12 ontology updates |
| Desk agent rebuilds | 144 | 0 |
| Desk agent test cycles | 144 | 0 |
| Desk agent releases | 144 | 0 |
| Behavior evaluations | 144 in desk pipelines | 144 automated in the gym |
Back at the FX desk, the practical test is simple. The trader asks about Halden again. The agent finds Asset Management at 23.3%, explains why the trade needs the Credit Committee, and leaves the CRO’s delegate with no excess request to approve. The risk team changed that answer for two different harnesses with one policy edit.