Coding agents are getting very good at doing work. The part that still looks wrong to me is what happens between the steps: the system keeps rebuilding project state that already exists.A planner creates a plan. A coding worker changes the repository. A tester finds a regression. A reviewer makes a decision. Then the next worker starts — and much of the same project context is assembled again: plans, progress files, diffs, logs, test output, and previous decisions.The problem is not that the model forgot one fact. The problem is architectural: the working state of the project is still too often attached to the agent session.The Project Should Be the Persistent ObjectThis is the assumption behind Tenrec. Instead of trying to keep one agent, one conversation, or one context window alive, Tenrec keeps the operational state of the project outside the worker: goals, tasks, accepted decisions, validated evidence, artifacts, failures, and recovery state.What Changes When the Project Owns the StateIn Tenrec, workers are deliberately replaceable.A worker receives a task, the relevant project state, and the tools it needs. It produces a candidate result. That result is validated before it becomes part of the persistent project state.The loop is:Project State → Relevant Context → Worker → Validation → Updated Project StateThis matters because a model response is not automatically treated as truth. A failed test, rejected change, or incorrect assumption should not become permanent knowledge just because an agent generated it.The persistent object is the project. The workers are execution units around it.Memory Is Only One Part of the StateThis is also why I do not describe Tenrec primarily as an “agent memory” system.Memory is useful, but project state is broader.It includes active tasks, dependencies, accepted decisions, artifacts, test evidence, failures, recovery state, and validated facts.A memory router is used to decide what a worker needs to see, but the objective is not to retrieve everything that might be semantically related.The objective is to reconstruct the minimum useful working state for the current task.That distinction becomes important when an agentic workflow runs for hours instead of minutes.The Unexpected Part: Tenrec Can Start More ExpensiveI wanted to test whether this architecture actually reduced context rather than simply sounding cleaner on a diagram.The result was not “Tenrec is always cheaper.”On a short Nemotron run, Tenrec initially consumed slightly more input than the transcript baseline. Structured state has overhead.But the baseline kept growing as more history accumulated.Tenrec did not grow at the same rate.That produced a crossover.In the longer controlled runs:DeepSeek V4 Flash 073139.3% lower cumulative input in the normal run40.2% lower cumulative input after a forced restart28.0–31.5% lower peak contextNVIDIA Nemotron 3 Nano 30B A3B32.0% lower cumulative input in the normal run34.7% lower cumulative input after a forced restart16.8–18.0% lower peak contextThe model-call count, tool trajectory, and validation path were kept the same.All runs completed successfully.The interesting result for me was not the exact percentage.It was the shape of the curve.A transcript-based system keeps paying for accumulated history. A project-state runtime pays some structural overhead, but the worker context can remain bounded.Restarting Should Not Mean Starting OverThe same idea applies to recovery.A process can die. A model provider can change. A worker can be replaced.That should not force the system to rebuild the entire project from an old conversation.Tenrec persists the accepted project state and reloads it after restart. The next worker receives the relevant state and continues from there.No agent identity needs to survive.That is the point behind the phrase:Agents are temporary. The project is not.What About LangGraph?LangGraph already provides durable state and workflow persistence, so the comparison is worth making carefully.I do not think the distinction is that LangGraph “cannot persist state.” It obviously can.The difference is the primary abstraction.LangGraph is centered on stateful workflow execution through graphs, nodes, and edges.Tenrec is centered on the project itself as the durable object, with tasks and replaceable workers operating around that state.In short:LangGraph persists a workflow. Tenrec persists the project.That does not make one universally better than the other. It is a different persistence boundary.What This Benchmark Does Not ProveThere are limits to the current results.The benchmark uses a controlled repository workflow rather than a production codebase with hundreds of thousands of lines.The current baseline is transcript-oriented and does not yet include a stronger compaction or summarization strategy.And the long-run results currently come from one full run per model.So, I would not claim that Tenrec universally reduces AI costs by 32–40%.What the experiment does show is narrower:When the same long-running workflow is executed with persistent routed project state instead of repeatedly replayed working history, cumulative model input can fall substantially.That is enough to justify testing the architecture further.The Bigger QuestionModels will keep changing.Today, it may be Claude, GPT, Gemini, DeepSeek, or Nemotron. Tomorrow it will be something else.I do not think the project should have to forget everything every time the worker changes.The model should be replaceable.The worker should be replaceable.The project state should survive both.Tenrec is my attempt to build around that assumption.The runtime, benchmark scripts, and raw benchmark results are open source:https://github.com/veritiana/tenrecPersist the project, not the agent.