Yesterday a Redditor posted that after a year of planning, they’re finally starting to write code for something called Violator.ContextOS. Yes, the subagents are velociraptors. No, I’m not kidding.
This is a plan, not a release. There’s nothing to download, and the author says to expect something cool “within a year.” What’s worth your time is the design, because a few of the ideas are useful today.
What’s new
The idea is to treat the AI like a CPU inside a small operating system, instead of a chatbot with a long transcript. The harness manages context for the model. The model just does the thinking.
The context gets split into chunks: memories, task list, token counts, agent statuses, and one chunk for the live conversation. That conversation chunk fades through summarization as it ages. A database keeps the full history, so nothing is truly lost. One chunk always holds the current objective, so the agent can’t wander off.
Think about how this differs from what most of us do now. Normally the whole chat is one giant blob, and the thing you said in message three gets buried by message sixty. Here, the important stuff lives in its own slot and gets reloaded every turn. If you’ve ever watched an agent forget the one rule you cared about most, you can see why this matters.
The twist
The subagents talk in a tiny compressed vocabulary:
- KNOW: here’s your context and constraints
- POUNCE: do the task
- RETURN: here’s what I want back
- HISS: done, here’s the result
- GOOD BITE: result accepted
- CLEVER GIRL: this lesson goes into the wisdom system
- SCRATCH: the task needs something your constraints forbid, so ask for a review
- WRE?: the assignment is too vague, so rewrite it
The joke is a real design choice. It’s a strict protocol that cuts ambiguity between agents. A free-form message like “hey, could you maybe look into the pricing page?” can be read five different ways. A fixed message with constraints, a task, and a return format can only be read one way. There’s also a background agent called RaptorJesus that reads the finished work and writes lessons learned for later runs. I can’t promise it works, since it isn’t built yet. The idea is still solid.
Steal the idea: a mini-workflow you can run this week 🦖
- Pin the objective. Put one short “current goal” block at the top of your prompt or project instructions. Repeat it every session. This is the anti-drift trick. Example: “Goal: ship the signup page copy, three variants, under 120 words each.”
- Split memory from chat. Keep decisions, settings, and specs in a separate notes file. Let the chat itself be disposable. If you can close the window and lose nothing important, you did it right.
- Summarize old turns. Every so often, ask the model to compress the older conversation into a few bullets. Keep the notes file and drop the rest. A good moment to do this is whenever the model starts repeating itself.
- Give agents a strict handoff format. Three fields is enough: context and constraints, task, expected return. Add a rule that says “if the task is ambiguous, ask instead of guessing.”
- Add an independent check. Have a fresh context review the work and list problems before you accept it. A model saying it succeeded is not the same as proof. The reviewer should not see the original chat, only the result and the requirements.
- Save the lessons. After each run, write one line about what went wrong and how you fixed it. Feed those lines back in next time. After a month you’ll have a short list that quietly makes every run better.
Pro tips
- Don’t tell the model to “act like an expert.” The author feeds in the actual expertise and tells the agent to use it. Paste in real reference material instead of a persona. A one-page style guide beats “you are a world-class copywriter” every time.
- Keep each agent’s context as small as the job allows. Smaller context means fewer chances to drift. If a helper only needs to rename files, it doesn’t need your whole project history.
- Start with the boring base, as the author plans to: one harness, a few model profiles, a versioned prompt library. Add complexity only when you hit a real need.
- Version your prompts like code. When results get worse, you can check what changed instead of guessing.
Reality check: the post is long on architecture and short on proof, and it had almost no reaction when I read it. Treat it as a design sketch. Still, the context-chunk and handoff ideas cost nothing to try.
Try steps 1 and 2 on your next project and see if your agent stops forgetting what it’s doing. Then tell me which raptor command you’d add. 🦖
After a year of intensive work, I am finally starting work on my thing. 🦖
by u/NovatarTheViolator in PromptEngineering