The result sits at the back. FlowGrid is trying to preserve the process in front of it.
FlowGrid began with a very specific working condition: I use several models and agents on the same project.
Codex, ZCode, and Hermes are useful for different things. Model capability changes. Costs differ. Subscription capacity runs out. Each tool has its own permissions and execution environment. I assign work to whichever agent fits the task, then move the project to another one when the conditions change.
Every switch creates a chance for the project to forget itself.
The next agent can read files and inspect a conversation. It may still miss why the project reached its current position, which directions were rejected, which conclusions have only partial evidence, and which boundaries took several rounds of discussion to establish. I have to explain the project again. A short explanation can revive an old plan. A complete explanation turns into another onboarding session for a machine.
That was the first problem FlowGrid set out to address.
The practical question was how to preserve project context across AI agents without letting every remembered statement become current truth.
Why AI agent handoffs lose project judgment
I roughly divide my work into two categories.
Software development usually has a relatively concrete destination. Code, tests, and runtime behavior remain available for the next person or agent to inspect.
Strategy, marketing, content, research, operations, and proposal work behave differently. Much of the work goes into defining the problem, setting boundaries, weighing trade-offs, and revising a judgment. My estimate at the time was 80 percent.
The final document often retains only the conclusion. The valuable middle stays scattered across conversations: why option A was rejected, why option B was accepted for now, which fact has been confirmed, and which claim still needs evidence. The deliverable survives the handoff. The path that produced it breaks.
The output can survive while the judgment process behind it disappears during a handoff.
FlowGrid is meant to preserve that layer. It records what the project currently accepts, doubts, rejects, and needs to do next.
Why FlowGrid starts with a local, auditable project ledger
The early design was deliberately plain: a local folder, a CLI, and Markdown.
The project directory is the highest-priority source of truth. The ledger travels with the project. A person can inspect it and an agent can read it. Plain files support diffs, version history, and human review. The project does not have to surrender its memory to the private memory of one model.
Writes follow a patch-first policy. An agent can propose a change, while a formal judgment still requires confirmation. That adds a small review step. It also reduces a more expensive failure: one model records an inference as fact and every agent after it treats the inference as settled history.
Agents can propose project judgments. The formal ledger still needs an explicit approval step.
Those choices define FlowGrid's early form. It is closer to a project protocol and an auditable ledger. It does not currently route models, assign tasks automatically, or manage a fleet of agents.
The reason it began and the product claim are different
Working on one project across several models and agents was the primary reason I started building FlowGrid.
Its current product claim is narrower: project state should remain resumable, and judgment should remain continuous.
The two statements describe the same experience but serve different purposes. The origin explains how the problem appeared. The product claim limits what FlowGrid is supposed to deliver. If a future version of me, a new session, or another tool can recover the current project state accurately, agent handoff follows naturally. FlowGrid does not need to become an agent orchestrator, a general Agent Memory platform, or a team collaboration system.
That boundary matters because models, agents, and execution environments will keep changing. FlowGrid is concerned with the judgment state inside the project. It does not need to predict the next tool that will carry it.
Eighth place separated retrieval from governance
I later moved part of the retrieval approach into an independent track called FlowGrid AML Retriever and entered the first public open-method evaluation on the Agent Memory Leaderboard. It has a separate repository, version history, and evaluation record from FlowGrid Core.
The retriever scored 43.98 and ranked eighth among the 51 public system submissions in that leaderboard snapshot. It finished 1.08 points behind the top entry.
The result supports the retrieval engineering. The system preserves every raw message and adds three retrieval views: individual messages, sliding windows, and session segments. It combines SQLite FTS5, Chinese character n-grams, exact entity, number, and date matches, adjacent context, weighted reciprocal rank fusion, and deduplication. Each result remains traceable to its source evidence.
The category scores provided the more useful constraint. In a recalculation across those 51 submissions, the system ranked eighth for relational and multi-hop retrieval and fourth for context rules and workflows. It ranked 42nd for memory governance and 40th for personalization. Strong retrieval did not supply reliable temporal state, conflict resolution, or personalized judgment on its own.
I did not merge the competition track back into FlowGrid Core. The two tracks continue independently. AML can test retrieval methods quickly. Core only absorbs capabilities that survive ablation and real continuation tests. Retrieval finds evidence. The FlowGrid ledger determines status and boundaries.
Eighth place is evidence about the retrieval track. It is not product validation for FlowGrid Core. For me, the result acted as a boundary test: project evidence can become easier to find while the project still needs an auditable governance layer to decide which evidence represents its current state.
What remains unproven
FlowGrid has run through a local-ledger workflow, a complete CLI loop, and several continuation evaluations. The product is still in its v0.3.0 and v0.4 validation stage.
The evaluations so far show that a Context Pack can preserve project boundaries with less context and perform reliably better than a stateless handoff. It has not consistently beaten a short, clean source history. Its compression value in long, contradictory projects, the stability of its provenance chain, and its quality across repeated handoffs still need more evidence.
My current conclusion is limited. The problem is real. The protocol and ledger can run. The product value is still being calibrated through real projects.
The next step is to keep handing the same long-running project to different agents and check whether they find the right starting point, preserve confirmed boundaries, and stop when the evidence is incomplete.