a2w / rouse

Rouse: Technical Writeup

7 August 2026

We believe good multi-session model awareness is possible through clever context engineering combined with determinism. We have been testing our idea in our agent and we believe it works well - so we extracted its memory system and called it “Rouse”. Available at github.com/a2wio/rouse.


What is Rouse

In its simplest form, Rouse is two things: a modularization technique, and a loop.

Before you continue with this article, it might be helpful to take a quick look at Rouse’s system design. It can be a handy point of reference when we go over the core concepts:

Rouse system design: a harness with its system prompt, skills and tools on the left; rouse.md, persona, beliefs, motivations and intentions as modular context in the middle; inventory and a clock that monitors and wakes on the right.

Context Modularization

There is a very good recent article from @trq212 on modularization: [link]. In its core, it goes over one of the very first things you learn in software engineering - structure. Which for us, as individuals previously spending a lot of time on GitOps & Infra, made a lot of sense when looked through our newfound eyes as AI Engineers.

Rouse’s core value (as we see it) is separation of context, a system we call “the ladder”. It looks like this:

The rouse memory tree: persona.md and entrypoint/ with rouse.md, beliefs/ and motivations/ above the line as context with no clock; intentions/ and the records below it; inventory/ with notes, probes, reminders and backlog.

Following a declarative feel (as markdown files are), it becomes clear what goes where: persona.md handles communication styles, rouse.md gives the model instructions on how to use its memory, beliefs/ holds ground truths (think work rules), motivations/ hold trigger signals context, and intentions/ is the logical basket for where tasks go. An intention is practically a loop.

And in inventory/ we hold one-offs that the model (in whichever harness it lives) can utilize for various end results. These are interactables that the core system has for disposal and for… well, interaction.


Looping markdown?

When you think of loops, it makes sense to think of deterministic software. After all, if there is no exit condition, how do you know you won’t be stuck in an infinite loop? Sure, one can argue model turns is a non-deterministic loop (which it is not) that the model making use of its loop decides when it ends, but that brings a question: how do you make sure it ends in the right shape? In other words, you can’t make it into a system if you can’t pin it to a specific structure.

In Rouse, we do this by utilizing markdown headers and two simple scripts:

An intention's frontmatter: status open, opened and last-moved timestamps, stale-after 2h, and a closes-when line.
one intention’s markdown header

The python scripts watch the status, the timestamp of when it was opened, and the last-moved key. Based on the ‘stale-after’ condition, if it is > last-moved (or respectively opened, if there’s not yet a move), the script packages a set of instructions to present to the model on its next turn — which happens by the model having the ‘rouse.md’ context fed to it at session start:

Terminal output of `python3 -m rouse due`: one intention, verify-the-staging-migration, stopped 5h ago, with its full path under entrypoint/beliefs/motivations/intentions.

This, combined with a simple looping mechanism, allows for every next session to start by having an understanding of what is outstanding and what the status is.

And here is how an intention looks, visually (from our own agent harness):

An intention rendered as a timeline: 2026-08-05-multipersona-build, done, 2h 58m from open to close, with its closes-when line and a track of task and flicker markers.
This was 2 hours and 58 minutes of looping over, with a new sub-agent every time, following a “conversational→worker” setup.

Miscs

Other than the core features, there is an inventory/ directory, which holds “one-offs” for the agent to track - notes/, backlog/, reminders/ etc. A note is essentially a little reminder for what happened during an intention (did it close successfully, did it fail, what failed, etc.) - all of this can be tuned in either your system prompt, {FILLER}.md, or rouse.md.

For what can you use Rouse?

We have used Rouse in our internal agent for Software Engineering tasks and Social Media work for the past 3 weeks, where we spawned a sub-persona (each bearing its own Rouse persona) for each domain.

The agent acts well and we can safely say the work we’ve been doing is top-tier for what we are delivering. One downside we see to the Rouse model is (since its context flipping is heavy) longer wait intervals between tasks.

(but this can also be observed with official harnesses / memory systems in the cases where a person lets a model write a thorough prompt of what they want…)

We believe Rouse can be used for any specialized task by configuring a persona for that task, although we highly believe it shines the most when wired into a fully-autonomous agent (a harness like OpenClaw or Hermes -or_our_own- that includes some sort of ‘wake’ mechanism).


Closing

This is pretty much it for a launch post. We hope you like Rouse and please feel free to text us on email (dennis@a2w.io / darling@a2w.io), or directly on X (x.com/@kuberdenis).

Take care, and please DO start a chat if you end up trying Rouse.

— Dennis


Resources:

Github: github.com/a2wio/rouse

Website: a2w.io/rouse