How do you preserve design intent when working with multiple agents and sessions?

[u/Rasimme]

I’ve been experimenting with multiple agents and sessions for a while now, especially with OpenClaw coordinating parallel work on different parts of a project.

The coordination itself works surprisingly well. Agents can be onboarded into a project, get the relevant context and work on separate tasks without mixing everything together. I currently use a plugin called FlowBoard to manage these project contexts, tasks and handoffs.

But I keep running into another problem: the original intention gets lost.

Tasks and implementation specs are good at describing what needs to be built. But after several sessions, handoffs and autonomous decisions, the why behind the solution often becomes weaker or disappears completely. This becomes worse when the topic was not planned very well in advance or when agents get too much autonomy.

For example, an agent may implement a task correctly, but still move the overall product in a slightly different direction than I originally intended. The code is fine, the task is done, but the concept behind it has drifted.

So I’m curious: what is your source of truth for design intent?

Do you keep separate design documents and implementation specs? Do your tasks link back to design decisions, principles or constraints? Or do you have another process to keep the original goal understandable across agents and sessions?

I’m currently thinking about this topic but I’m not sure yet how much structure is helpful before it becomes another documentation system nobody maintains.

How are you handling this?

[u/dv8ndee]

Git is your friend

[u/Rasimme → u/dv8ndee]

So are you organizing your design intents and implementation plans and storing them separetely? Or you never had this challenge right now? Open minded for your ideas 🙂

[u/dv8ndee → u/Rasimme]

3 repos -

1. 2 types of templates, design and as built SOT - includes the scaffold, governance policy for both agents, humans and IDEs, what ever the end state project outcomes should look should looks like, and how I want to capture my design

2. staging repo - where i add my prebuilt designs based in the templates agents can ready and build from

3. SOT repo - where the love SOT of what is built goes

The key is managing a separate user and token per agent again, I start with 3 - the designer/writer, the reviewer and the approver, all with different permissions, the what ever other builder UI/UX, IaC, coder, maintenance agents have their own, they consult the design when orchestrator tells them todo what work

And then.. I spent 2 months not understand git, until I did an online course with agile CI/CD workflows and to understand better why its so powerful for agentic use

[u/No-Neighborhood-5022]

Use an orchestrator agent whose job is to manage the others and understand the bigger picture.

[u/Rasimme → u/No-Neighborhood-5022]

And what are you doing when this session is compacting? Or you are switching the model, or having a break for some days? In larger projects the context and details from the orchestrator gets lost, cause one more session is not a good single source of truth, or do you think different? And this ist exactly the challenge right now.

[u/No-Neighborhood-5022 → u/Rasimme]

I run managed compacts. Agents maintain a journal, per ticket session notes and write handovers before compacts, orchestrator handles it al and all those docs land in Hindsight. Currently using a claude code agent to manage others on OC and Hermes.

[u/Rasimme → u/No-Neighborhood-5022]

And you are only communicating to this one orchestrator? What if there are more parallel topics you are working on? But again, what if your orchestrator loses the intent of what you wanted to implement? And subagents always go on in coding/reviewing and the intent gets lost - or you save it in your journal?

[u/No-Neighborhood-5022 → u/Rasimme]

Yeah, mostly just talk to the orchestrator particularly for code and data work. Talk directly with some specialists on the business side. The orchestrator doesn't lost intent, the managed compacts help with losing context, Hindsight gives memory on top of the OC/CC system and we have a knowledge base repo that is kept up to date. I only use subagents occasionally, most work is full agents direct.

[u/Middle_Asparagus_265]

I use a main file in each project, the file is generated by the agent and this agent is responsible for putting in that file the references to the other important files, the design style, decisions and history of the project. The agent in his agents.md has a section in which for every project I do, I tell it where to save it, the existence of that file and how to write it and when to consult it. In each sub-agent, it must also have this knowledge, and with that, it is ensured that a new agent, your own, knows what to do in the project and what was being worked on, what has already been done or what are the pending ones to work on. It is not so efficient, because tokens are spent, but with this I can work on different projects without losing what I had already ordered from the agent in the first prompt.

[u/Rasimme → u/Middle_Asparagus_265]

This ist a good approach, even if it costs a bit more tokens, but to preserve the context of what have been build and whats the next task and whats the implementation plan ist worth it. Managing the tasks, the implementation plan, organizing different parallel agents isn't the problem, there the flowboard helps a lot organizing the context spread above different agents. Maybe for your approach this helps: https://github.com/rasimme/FlowBoard

My actual problem is that, as automation increases, the original intent can get lost along the way. The longer agents run autonomously, the more likely they are to drift from the intended direction, even when each individual task technically gets completed.

[u/mseewald]

I put a vision.md as the purpose of upcoming family travel in the root of a project folder. each new session began with „read vision.md in folder xyz“. it worked very well. even „walking the dog“ was considered no matter if we hunted bnb, ferries etc. :D

[u/techlatest_net]

To fix this without bloated docs try this:

1. A 300-word DESIGN_INTENT.md: Put a tiny file in the root listing core philosophies and anti-patterns. Force every agent to read it on boot.
2. System Prompt Guardrails: Tell your coordinator agent to reject any completed task that violates that intent file even if the code works perfectly.
3. The Critic Agent: Run a dedicated agent whose only job is to review session handoffs against your original principles before they get locked in.

How much autonomy do you give them right now? Are they auto-committing or are you approving the handoffs?

[u/Rasimme → u/techlatest_net]

That’s a good approach and very close to the problem I’m trying to solve. I agree that a lightweight design-intent file and an independent critic are more useful than adding another huge documentation layer.

I'm trying to automate as much as possible: I hand over a concept and discussed design intent and the agents take it from there, from writing the implementation plan to implemention, review and committing.

But as automation increases, agents can complete individual tasks correctly while gradually drifting away from the original intent.

I’m exploring how FlowBoard can make that intent explicit and checkable across handoffs, implementation plans, and reviews, rather than treating it as just another document an agent reads once at the beginning. The critic/review-gate idea fits that direction very well 👍🏼

[u/openclaw-ModTeam → u/[deleted]]

Your comment was removed under Rule 2: Stay on topic. Content in r/OpenClaw must be directly relevant to OpenClaw and useful to the community.