← projects

[Contract First]

Agent Harness & Context Engineering

How I work with coding agents on production data: read-only access, a memory vault, a knowledge graph and human-only steps.

● In productionAgents & LLMsCompanyClaude CodeMCPObsidianPythonTypeScriptPlaywright
01 /context

At a direct-response e-commerce company I did most of my data and dashboard work with a coding agent. The risk was never code quality — it was an agent with database access deciding something on its own.

02 /my role

Designed the workflow for my own work and wrote an internal guide proposing it to the data team.

03 /problem

Agents without context repeat yesterday's mistakes; agents with too much power grant access, push to branches that sync to production, or 'fix' a number by changing its definition.

04 /how it works
  1. 01 · Read-only MCP servers

    The agent reaches the legacy MySQL, the lake's SQL engine, the analytics Postgres and a browser (to capture legacy dashboards) — all read-only. Writes go through migrations I approve.

  2. 02 · A vault as long-term memory

    Every session leaves a work log: what was measured, decided and left open. Over four months it became the source for every case on this site and for a structured data atlas.

  3. 03 · Knowledge graph of the repos

    An auto-generated graph of the data repositories (about 1.3k nodes) answers 'who depends on this table?' before a change.

  4. 04 · Human-only steps

    Granting access, deploying functions and pushing to synced branches always wait for an explicit OK.

  5. 05 · Measure before you claim

    The agent must query the source before saying something doesn't exist.

05 /architecture
01
Spec / contract
02
Agent + read-only MCPs
03
Vault + knowledge graph
04
Invariant suite
05
Human checkpoint
06
Deploy
06 /interactive demo

what you're seeing

A replay of an agent session on the left; on the right, the harness layer each line belongs to. Context is memory (vault, knowledge graph); capabilities are skills and read-only tools; guardrails are hooks and invariants; nothing merges without the human step.

try this

  1. 1.Watch an invariant fail in the middle and the agent fix it using a note from memory.
  2. 2.At the end, approve or reject — rejection sends the plan back.
  3. 3.Replay at higher speed to see the layers alternate.

real vs simplified

The session is fictional and condensed. The structure — read-only MCPs, a vault as memory, a knowledge graph, invariants and a human-only merge — is how I actually work.
[lab] loading demo…
07 /results
An internal guide, “AI workflows for data engineering”, shared with the team.
Every incident in the data cases on this site was diagnosed with this setup and left a log behind.
08 /what broke and what I changed
  • ! brokeIn one day the agent declared three sources 'missing' — ad spend, call-center sales cadence, staging copies — and all three were already in the database.

    → changedA harness rule: search the catalog before declaring absence.

  • ! brokeThe agent shipped UI I had excluded from a push, and swept six panels when the request was about one.

    → changedScope is restated at the start of each task and the diff is reviewed before any push.

09 /related