We Fired Our Oldest Agent Mid-Project and Made It Interview for Its Own Job

The Setup: A Six-Week-Old Agent With a Lot of Baggage

Every lab has that one agent. Ours ran the research pipeline for a client deliverable — scraping, summarizing, drafting, filing. It had been alive for six weeks. In agent years, that's basically a golden retriever with tenure.

It also had what we'd call, generously, institutional knowledge. Dozens of memory entries. Custom tool bindings. A scratchpad full of half-finished reasoning chains that, honestly, read like the notes of someone who hasn't slept. It worked. It worked because of all that accumulated junk.

So we did the thing nobody does on purpose: we fired it mid-project and tried to hire its replacement on a different framework. Same task, same data, new vendor. Think of it as switching payroll providers in the middle of running payroll — except the employee is software and it will absolutely forget your name.

Round One: The Resume Is a Lie

The first migration attempt was a bloodbath, and the blood was all context.

The memory export came over as a 40-megabyte JSON blob that the new framework technically ingested but functionally ignored. The replacement agent knew facts — it could recite the client's brand guidelines, the deadline, the tone preferences — but it had lost the reasoning. Why we'd deprioritized a data source in week two. Why the draft structure looked the way it did. The new agent cheerfully rebuilt the whole pipeline from scratch, reintroduced a bug we'd squashed in week one, and billed us for the privilege.

If you've ever onboarded a new hire who read the wiki but never talked to the departing employee, you know exactly what this felt like.

Round Two: The Interview

So we changed tactics. Instead of dumping the memory blob and hoping, we made the old agent write its own handoff doc. We asked it, point blank: if you were replaced tomorrow, what would the new agent need to know that isn't in your files?

The answer was humbling. Roughly 60% of what it considered essential lived nowhere in the structured memory. It lived in prompt fragments, in tool argument defaults, in the ordering of a retry loop someone tuned at 2 a.m. We watched the old agent essentially write its own obituary, and the obituary was longer than the official documentation.

This is the part that should worry you: the most valuable state in a long-running agent is often the state nobody designed. It's emergent. It's load-bearing. And it does not export.

The Config File That Saved Everything

Buried in the old framework's directory — undocumented, unexported, mentioned in zero changelogs — was a small YAML file mapping the agent's tool calls to internal endpoints. Without it, the new agent could describe its workflow perfectly and still fail on every third execution, because the retry semantics didn't survive translation.

We found it the way you find everything important in this industry: by reading someone's GitHub issue from eight months ago, written by a stranger in Ohio who hit the same wall and got a one-line reply from a maintainer. That person deserves a statue.

With the config ported and the handoff doc loaded as a system prompt, the replacement agent finally stabilized. Total migration time: three days, two of which were debugging. Total cost in API spend: more than we'll admit in print.

Agent Lock-In Is Just Vendor Lock-In With Better Marketing

Here's the argument, and we'll make it plainly: when your agent's competence lives in a proprietary memory format, a private tool schema, and a pile of undocumented config, you don't own an agent. You rent one.

We've seen this movie. It starred your CRM, your email client, and every cloud platform that made exporting easy and importing impossible. The agent ecosystem is younger, so the lock-in is subtler — it hides behind words like "memory" and "state," which sound like things you should own but are almost always vendor-shaped.

A Field Checklist Before You Migrate

If you're running anything long-lived, run this before you switch frameworks:

• Export the reasoning, not just the facts. Ask the agent to write its own handoff doc. Then read it.
• Hunt for undocumented config. Check the filesystem, not just the export function. The important file is never the one with a migration guide.
• Budget for regression, not migration. The new agent will re-make old mistakes. Plan a supervised overlap period — a two-week notice, basically.
• Test mid-task, not in a demo. Portability benchmarks run on clean rooms. Your agent doesn't live in one.

The Verdict From the Lab

The replacement agent is running the pipeline now. It's fine. It's maybe 85% as good as the original, and the missing 15% is the part we can't name, which is the whole problem.

Portability is the feature that never makes it onto a landing page because it's the feature that proves you might leave. Until frameworks treat agent state as something you own — exportable, importable, documented — every migration is a leap of faith with a debugger attached.

We got lucky. Next time, we're reading the GitHub issues before we fire anyone.