FIELD NOTES / AI LAB
I went from asking AI for help to directing specialized models and preserving their knowledge across projects, sessions, and devices.
This is a personal log of how I moved from asking models for help inside chat windows to directing specialized models, agents, skills, MCPs and portable memory. It is not a service pitch.
01 / ODYSSEY
How I went from chat windows to a real harness
The chronology below distinguishes model changes, interface changes, and authority changes. It is a personal account; private employer work and its metrics are self-reported and are not independently verified in this public portfolio.
CHRONOLOGICAL TIMELINE
XtendOps: building AI before programming with AI
I helped build a configurable agent platform that used GPT, Amazon Bedrock and other technologies depending on the client.
HelloFresh was a client of XtendOps; it was not my direct employer and the tool was not exclusive to HelloFresh.
One RAG case returned real-time information, fragments of real terms and conditions, and links back to the sources.
I worked around variables, chat pause and user experience.
At that time GitHub Copilot showed up as autocomplete inside the IDE, not as an agent.
Sekura: ChatGPT web and bounded context
I built a claims management application with React Native and Metro.
It reached production on an accelerated delivery timeline and saw substantial client adoption.
I created a reusable component system based on React Native Paper.
Professional AI work happened in ChatGPT web: I copied and pasted specific blocks.
I learned that a small, direct context produced fewer hallucinations.
When the model lost the thread I diagnosed manually and came back with bounded instructions.
The first IDE agents in this stage were personal experiments, not part of office work.
Claude and Gemini: switching providers for clarity
At Zorya, a Meta onboarding change required working in C# while I was still new to the language.
Claude 3.5 Sonnet resolved and explained the change clearly enough that I moved my primary subscription from OpenAI to Anthropic.
Claude 3 Opus was occasional support.
Gemini 3 Pro became a daily tool because of the Google ecosystem; I refreshed the page waiting for its launch.
Gemini 3.1 Pro arrived later as support and an architecture second opinion.
From interface to harness
Claude Code Desktop was the bridge from my preference for graphical interfaces.
The CLI brought control, visibility, subagents and configuration.
OpenCode Desktop arrived before OpenCode Go.
My first deliberate pair: GLM-5.1 as planner and Kimi K2.6 as builder.
MiMo-V2.5-Pro replaced Kimi K2.6 as builder.
MiniMax and real orchestration
I adopted MiniMax M3 on launch day and paid for MiniMax Token Plan the same day.
MiniMax M3 started as planner and builder.
Later I used Claude Code with Claude Opus 4.8 or Fable 5 as planner and OpenCode connected to minimax.io as builder, both on the same repo.
After that I went back to MiniMax M3 as planner and builder and reached roughly 1.07B tokens in a monthly period.
The next flow used GLM-5.2 via Z.AI as planner and MiniMax M3 via minimax.io as builder, all inside OpenCode.
GLM-5.2 was the first planner I left working for hours while I was away or asleep.
I stopped evaluating providers by brand and country of origin as a single block and moved to assigning models by role. GLM took the planner seat. MiMo and later MiniMax took the builder seat. Kimi fell out of the rotation after its run.
Here the first designed orchestration appeared: the planner could not write code and delegated to specialized subagents on the same workspace.
Codex and Sol
Sol is the root planner and architect.
In Codex V2 without agent_type, MiniMax M3 receives implementation through the direct minimax-builder runner.
agent_evaluator and silent_failure_hunter have read-only runners.
Generic Codex agents are not described as MiniMax.
Phases stop at human gates.
02 / HOW I PROGRAM
Five rules that came out of the odyssey
-
I bound the context before asking for code
Repository rules, prior decisions and dependency contracts reach the model before the request does.
-
I diagnose manually when the model loses the thread
If the response drifts, I reopen the problem and narrow the scope instead of asking for a continuation.
-
I separate architecture from implementation
Architecture decisions stay in a planner role; implementation units travel through bounded briefs to a builder.
-
I verify configuration, dispatch, inference, telemetry and product behavior as separate checks
A green response from one layer is never taken as proof that the next layer works.
-
I keep human approval when a transition can change scope, data, cost or production
Anything that moves money, users, schemas or production state stops at a human gate.
03 / SKILLS
From repeated practice to a portable skill
When a practice repeats, I turn it into a versioned skill that travels between models and sessions. The list below is a curated sample, not a badge wall.
PUBLIC SKILL EXAMPLES
- frontend-design
- Build frontend interfaces with design judgment, not generic templates.
- design-review
- Run a 7-phase review covering WCAG 2.1 AA, responsive layout and visual polish.
- copywriting
- Write and review marketing copy with checkable structure.
- stop-slop
- Remove typical AI prose patterns from drafts.
- context7-mcp
- Pull current library docs before writing code.
- graphify
- Turn a codebase into a navigable knowledge graph.
- minimax-builder
- Run bounded builds against MiniMax M3 with auditable briefs.
- minimax-role-runners
- Assign roles to runners with bounded authority.
04 / AGENTS AND SUBAGENTS
From a single planner to a hierarchy with explicit authority
The harness moved from a single planner to roles with bounded authority, read-only audits and human gates.
First version of the harness
Four stable roles for plan, build, commit and memory.
- planner
- builder
- commit_creator
- vault_memorist
Later expansion
Three more roles for audit and release.
- agent_evaluator
- silent_failure_hunter
- release_noter
CHANGES IN AUTHORITY
Read the technical case study: how this system works →05 / SIDE ROUTES
Local, remote and inconclusive explorations
I tried running models outside the main flow. Some paths stayed open; others became learning without a clear use.
MacBook Pro M2 with 8 GB of unified memory
Local inference with Ollama. It served an unidentified Qwen quantization close to 5 GB.
Another PC consuming the server
Another PC consumed the local Ollama server.
VPS tests
I tested a VPS to operate agents remotely.
OpenClaw and Telegram bots
OpenClaw and the Telegram bots used MiniMax M3 with the same API key from the Token Plan. They still do not have a clear utility in my flow and stay as inconclusive explorations.
Mistral as a planned European route
I evaluated Mistral as a possible European provider. The motivation was data sovereignty, provider diversification, hosting location and reduced reliance on US providers. It never reached production in my stack.
Models developed in China, evaluated by role
I do not treat them as a homogeneous block. Qwen ran in a local Ollama test. GLM took the planner seat. Kimi and MiMo served as builders before falling out of the rotation. MiniMax took the planner and builder seats and runs the agent runtime. Each model earned its place on reasoning quality, context retention, tool integration, cost, the authority I assigned it and operational continuity.
06 / MCPs, ENGRAM AND KNOWLEDGE-VAULT
A portable layer that survives models, machines and sessions
- ORIGIN
- Engram comes from Gentleman Programming. It arrived almost at the same time as my need to share memory across laptops.
- PORTABLE LAYER I BUILT ON TOP
- Instructions, agents, skills and registries
- Setup, restore and portability scripts
- Mavis persistent memory
- Cross-runtime conventions
- RUNTIMES SHARING MEMORY
- Codex, OpenCode, Claude Code and Mavis share the same Engram base.
- BACKUPS
- Engram backups are encrypted with age and live in Google Drive.
- COMPARE-AND-SWAP
- The compare-and-swap mechanism stops an outdated laptop from overwriting the newest remote backup.
ORGANIC VAULT ORDER
- History and way of programming
- Skills
- Agents and subagents
- MCPs
- Memory
- Operational continuity
PUBLISHED VAULT COMMITS
- 2ff433e
- CLI registry
- 8763e00
- Codex policies and documentation
- 1756f02
- installer and runner registry
- 23562a2
- MiniMax builder and runners
At handoff time origin/main and HEAD both pointed at 23562a2. graphify-out/ and __pycache__/ remain excluded.
07 / FAILURES
Five incidents worth telling
INC-01
- SITUATION
- Large requests caused hallucinations; the model lost the thread halfway through.
- CORRECTION
- I narrowed the scope and came back with manually diagnosed blocks.
- EVIDENCE
- Short, bounded prompts produced useful answers again.
INC-02
- SITUATION
- An agent answered READY while the provider still showed 0% usage.
- CORRECTION
- Static configuration and real inference became separate checks.
- EVIDENCE
- A substantive API call confirmed the model and measurable token consumption.
INC-03
- SITUATION
- Codex V2 did not expose a safe selector for custom roles; generic dispatch could inherit the wrong model.
- CORRECTION
- I stopped generic dispatch and built a direct runner with an exact file allowlist.
- EVIDENCE
- The runner validates unified diffs and runs git apply --check before any file changes.
INC-04
- SITUATION
- A 13-file evaluator returned invalid JSON.
- CORRECTION
- I split the audit into four coherent subsystems and retried only the failing unit.
- EVIDENCE
- Four valid scorecards, identical workspace snapshots and an independent cross-review closed the audit.
INC-05
- SITUATION
- Available quotas forced me to ration every flow for several months.
- CORRECTION
- I adjusted the scope and rhythm of each flow to the quota available.
- EVIDENCE
- A sustained operational restriction for months, not an external metric.
08 / SNAPSHOT
A dated look at usage volume
AS OF July 16, 2026
USAGE METRICS
- tokens on GLM
- 101,686,799
- MiniMax total tokens
- 1.95B
- MiniMax tokens, last 30 days
- 1.53B
- MiniMax tokens, last 7 days
- 698.20M
- MiniMax peak
- 317.95M
Volume does not equal quality. This is a snapshot of use, not proof of value.
09 / HUMAN RESPONSIBILITY
What still stays mine
- Scope
- Decide which problem is worth tackling and which non-goals to defend.
- Data
- Choose what data enters the model and how it is isolated.
- Cost
- Approve subscriptions, plans and budget trade-offs.
- Production
- Approve deployments and routes that touch real users.
- Diagnosis
- Reopen the problem when the model loses the thread.
- Final approval
- Say yes or no before each transition that changes something material.
