One supplier, five agents, five AI platforms, one context

Four ways context goes wrong with more than one agent

• It is locked in. Memory kept by a model provider or an agent framework moves with that vendor, so switching platforms means starting over.
• Nobody checked it. An agent's memory is whatever it decided to remember, and a wrong lesson spreads as easily as a right one.
• The goal gets buried. Forty messages into debugging, nobody can say what the work was for, and a second agent picking it up gets a transcript with no clear state.
• Each agent does the job its own way. One asks for approval at the risky step, another checks a policy, a third just acts.

Context, in three parts

Underneath all three is a record. Every time knowledge or a playbook step is handed to a piece of work, Deliverd writes down when, to which agent, which entries, and who confirmed each one.

The agents

What Halden's agents already know

Halden's knowledge base already holds entries its people wrote, imported from a notes file, or confirmed from agents' proposals. These are the ones this job touches.

The job, written down once

Halden started from the product's Supplier onboarding check starter, linked the entries each step relies on, and added one step of its own: a gate on supplier.create before the supplier record is created. Its compliance admin put the playbook in force, which fixes its words; a change becomes a new version. A run needs: supplier, service, business_owner, uses_ai (optional).

Each check is a call the agent already knows: a review step means request_review, an approval step means request_approval, a gate step means check_gate for the named action. The step's goal names the call, so the risky moment is handled the same way whichever agent runs it.

Monday: a form starts the run

Halden's logistics manager fills in the supplier request form. The n8n workflow behind it starts the playbook over the REST API, with the inputs and the form's submission ID as an external ID, so a retried webhook returns the same run instead of a second one. Running a playbook starts an objective with the playbook's purpose and a side task per step, each holding its instruction, the inputs and the confirmed knowledge it relies on. Agents start the same run with start_playbook.

POST /api/v1/playbooks/{id}/start
{ "title": "Onboard Corran Freight", "externalId": "form-4471",
  "inputs": { "supplier": "Corran Freight Ltd", "service": "Regional pallet delivery with AI route planning",
              "business_owner": "Head of logistics", "uses_ai": "yes" } }

The procurement assistant in ChatGPT reads its step with get_task_context. It needs no long prompt about Halden: the context hands it the instruction, the inputs, the portal timeout (K4) and the legal-name convention (K5). On the gap check it finds Corran's insurance shows €2m cover, below the €5m in K2, and following K3 drafts one message listing everything outstanding. It records what it found with add_finding and calls request_review; the procurement lead approves the draft.

It also tries to save the supplier portal's login as knowledge. That is refused: knowledge goes to every agent that asks, so an entry that looks like a password, key or token is turned away. It proposes “the portal login is kept in the procurement vault” instead, with propose_knowledge, and the procurement lead confirms it.

Tuesday: a different platform picks up where the last stopped

The risk analyst runs in Claude, with no memory shared with ChatGPT, and needs none. Its context gives it the objective, the task state (insurance chase sent, next action: assess AI use), the decisions so far, and K1 and K6.

Corran's answers show route planning runs on a third-party model, and nobody knows where delivery addresses are processed. Rather than bury that in the main thread, the analyst opens a side task with create_side_task. It starts with a snapshot of the objective, not a copy of the conversation, and comes back with a result: the provider's region, its retention period, the evidence, and a suggested decision. A decision an agent records stays a suggestion until a person confirms it. The analyst drafts the risk summary and calls request_review.

Wednesday: people approve, and the gate decides

Corran sends a new certificate. Step 5 asks the head of logistics and the risk owner to approve with request_approval; both are asked because K1 says so. In Teams, a colleague asks the finance agent who to talk to about Corran's bank details. It answers from K7 with search_knowledge: an entry a person confirmed, not the model's guess. Then it calls check_gate for supplier.create and does what Halden's policy answers before it creates the record.

Thursday: a coding agent reads the same context from a file

An engineer building the sync to the finance system downloads Halden's context as an AGENTS.md: the confirmed knowledge and the playbooks in force. Cursor reads it like any other project file. Testing, it finds names over 60 characters are rejected and proposes that as a known issue with propose_knowledge. Once the integration lead confirms it, the next agent on any platform is given it.

deliverd knowledge agents-md --out AGENTS.md

What did the agent know when it acted?

A month later Halden raises the insurance minimum to €10m. The finance controller revises K2; once the revision is confirmed it replaces the original, which stays on the record as superseded. At the audit, someone asks why Corran was approved with €5m cover. The objective's page answers under Context it was given: the €5m entry, who confirmed it, and when it was handed to which agent.

deliverd knowledge given <objective-id>

Change platforms without starting over

When Halden moves its procurement assistant to another platform, there is nothing to migrate: the new assistant connects to the same MCP server and gets the same context on its first call. If Halden leaves Deliverd, its context leaves with it, as Markdown that imports into any organisation, as JSON, or as an AGENTS.md. Import works the other way too: each heading of a notes file you already keep becomes a proposed entry.

deliverd knowledge export --out knowledge.md
deliverd knowledge import CLAUDE.md

• An agent is given at most 8 relevant confirmed entries with a piece of work, so its context stays short. It can search for more.
• No agent confirms knowledge or puts a playbook in force, whatever its key allows.
• Context is included in Team, Business Starter, Business and Enterprise.