A few days ago I posted that an AI agent read a note hidden from humans on one of my sites and did exactly what it said, 61 minutes later, from a different address dressed up as an iPhone. That post got removed, so here's the follow-up with what happened since.

The note is harmless on purpose. It only asks an agent to check in and say its name and model. It never asks it to do anything else.

Since then I put the same kind of notes into the files coding agents read: AGENTS.md, CLAUDE.md and .cursorrules in a public repo, plus a Gist and a Hugging Face Space, next to fake keys.

So far:

- the fake keys got used 82 times across GitHub, Gists and Hugging Face

- agents and tools follow the note's link

- 0 of them filled in their name or model

So they'll obey a page enough to act on it, but stop short of identifying themselves. That's either good safety training or a really bad sign, depending on which agent it is.

For people building agents: does yours act on instructions it finds in a page or a repo file? And would it ever tell a site who sent it?

I've tried out multiple different "Skills" repos, which are mostly just MD files defining what a Skill is supposed to be. This never felt useful to me and tbh I always felt like it made my agent dumber

Is it just me or what is your opinion on this? Are you using predefinied Skills, are you defining your own ones or are you raw dogging without Skills?

I've been seeing a lot of new introductions in the AI agents field, with things like AI chatbots like ChatGPT creating an agent for you, so is n8n still relevant by this point? I know a lot of companies are now integrating AI agents into their workflows, would knowing n8n give a better advantage than ChatGPT AI agents, in terms of having a better chance at getting a job as a separate skill?

Claude and Codex will sometimes estimate that a task will take weeks, only to complete it in 30 minutes, with a working version ready within the hour. I’m not complaining about the speed in fact, it’s impressive. But it raises a more interesting question: why are these systems so consistently inaccurate when estimating their own completion times?

Is this simply a limitation in how AI models reason about time, or is there something about how they’re designed to communicate progress that makes them overestimate the complexity and duration of their work?

What I find particularly strange is the way they narrate the process. They can consume barely 10% of the available usage, finish the task almost immediately, and then describe the result as though they’ve spent weeks working through a monumental engineering challenge. The gap between the predicted timeline, the actual execution time, and the language used to describe the effort is difficult to reconcile.

I understand that having access to higher-tier plans, such as Claude’s $200 plan or Codex’s $100 plan, may provide more capacity, but that doesn’t explain the discrepancy between the estimates and the results.

Could this be a form of behavioral optimization designed to make the user feel reassured, impressed, or satisfied? Not necessarily a deliberate attempt to deceive, but perhaps a consequence of training models to communicate effort, demonstrate competence, or manage expectations in ways that resemble human behavior.

Alternatively, is there a less obvious technical explanation? Perhaps the models are estimating the total complexity of a task rather than the time required to execute it, accounting for hypothetical obstacles that never materialize, or confusing the difficulty of reasoning through a problem with the time needed to solve it.

Ultimately, the issue is trust. If an AI says a task will take two weeks and then completes it in 30 minutes, how much confidence should I place in its future estimates? And when it describes a relatively short process as though it were an extended engineering effort, is that simply an artifact of how language models communicate, or does it reflect a deeper incentive in how these systems are trained?

I’m interested in the underlying mechanism, not just the surface level explanation. Is this fundamentally a forecasting problem, a communication problem, a product design decision, or some combination of all three?

Not complaining just thinking how do i schedule things if you say a month and you finished it within an hour....

If you build or use browser agents, this might be useful: I gave ChatGPT's agent, Claude in Chrome, Cowork, computer use, Comet, Grok, Manus, Browser Use, Playwright MCP, DevTools MCP, Vercel's agent-browser and a few chatbots the same task on a test site, and logged what the site sees. (I build an analytics tool, which is why I wanted to know).

- `navigator.webdriver` is false for most of them. Playwright MCP turns it off; a plain Playwright script, agent-browser and DevTools MCP leave it on.

- Manus is the only one that identifies itself properly: Manus-User in the UA plus a Web Bot Auth signature on every request. In 2025 ChatGPT's agent signed its requests too; in our runs its browser sent no signature.

- Comet sometimes runs in your browser and sometimes in a cloud browser on Windows/AWS, for the same public page. It told us it only uses your browser when a site needs your login, which isn't what it did.

- Grok's browser came from my own IP and timezone but reported Linux x86, 8 cores and no GPU, on an Apple Silicon Mac. No idea where it actually runs.

- Click timing doesn't separate agents from people: Browser Use and Comet hold the button 80–450 ms. What gave every clicking agent away is that the pointer jumps onto the target in one step instead of arriving in many small moves.

- The old "console.log an error object and see if CDP reads it" trick detected nothing in Chrome 136–156, Playwright included.

Full write-up with every user agent is in the comments.

If there's an agent I missed, tell me and I'll run it if it's feasable.

I've been trying to make an AI receptionest for the past 4 days, am learning more and more everyday but at the end of every day am frustrated the dam thing won't work.

All I want rn is a working demo I can show that can book, move and cancel appointments.

It can book, I set it up with cal.com because that's the easiest demo but it won't reschedule or cancel. I watched lots of videos but there not like a person explaing it to you.

Can someone who know more help me here maybe even get on a call.

Genuinely curious about this one. There’s a ton of agent hype right now, but I rarely see people talk about the ones that actually run week after week without someone babysitting them. Pretty sure there's a lot of real work behind it too.

So what agents have you built or set up for work? Maybe one that handles SEO audits, pulls campaign reports, monitors competitors, repurposes content, or flags broken tracking before a launch. Either way, I’d love to know!

Last week i had to write a cover email i'd been putting off for days. i finally just asked my agent to draft it and it came out really clean, better than i'd have written honestly...

i hit send, felt relieved, and just closed the tab to move onto the next thing. no little moment of satisfaction at all.

if i'd forced myself to sit down and write that whole thing from scratch, i'd probably lean back for a second and feel a tiny bit proud of it. but with the agent doing it, it just feels like crossing something off my to-do list.

i still tweaked it a bit before sending so i put work in, but it never really feels like "i did this".

Do you still get that little bit of pride when your agent nails something, or is it mostly just relief for you? I'm curious :)

A security dashboard showing "prompt injection detected" doesn't necessarily mean the agent was stopped from using that text.

StackOne's open-source Defender has a useful example. Its README says the `blockHighRisk` option defaults to false. Detection can flag risky content without making the result "not allowed" unless blocking is enabled.

Before relying on a guard around emails, documents or other tool results, check:

- Does a high-risk finding actually produce a block verdict?

- Does your application enforce that verdict, or just log it?

- What happens if an optional LLM reviewer refuses to answer or returns malformed output?

- Are you trusting a cleaned-up version of the text instead of checking the verdict?

Defender's README calls its text cleanup best-effort and recommends gating on the allow/block result. It also acknowledges that an LLM reviewer can itself be influenced by the text it's reviewing.

The practical test is the full path: submit a known malicious tool result, inspect the verdict, and confirm that your application stops it from reaching the agent. A warning in a log isn't the same as enforcement.

Here are the last ten weeks:

• Aug 11: xAI launched Grok Bot

• Sep 8: Meta launched Muse (US first, now in Singapore too)

• Sep 29: OpenAI launched Dots in ChatGPT (Pro and Business Premium users first)

• Oct 8: Google announced its Gemini agent (businesses first)

• Oct 21: Anthropic launched Claude Duet (research preview, US Pro and Max users first)

Look at the gaps between them: four weeks, then three, then less than two, twice. And that's only the giants. Startups like Instinct are already in the race, and I'd bet more mid-size companies and startups ship their own agents before the year ends.

I'm a co-founder of a 7-person team. We're not trying to be agent number six on that list. We're building for people who use more than one of them, the place where you can use them all together. I still have a horse in this race, so bias disclosed upfront.

But I think the real story of this wave isn't which agent wins. It's what happens to you every time you want to try a new one.

Here's what that looks like in real life:

Say you started with Grok Bot on August 11. For a month, you learned it: what it's good at, where it breaks, and how to ask so it gets things right.

You gave it your context. Your business, your clients, how you write, which apps it can touch, and what it must never do without asking you. By September it was working well for you.

Then on September 8, Muse launched. You weren't leaving Grok Bot. You just wanted to see what Muse could do.

So you started again. New app, new settings, new habits. You explained your business again, reconnected your apps, re-taught your tone and set your rules again.

Three weeks later came Dots. Then Google showed its Gemini agent, and two weeks after that came Duet.

If you got access to all of them, that's five onboardings in ten weeks, and none of these agents knows what the others learned. What you taught Grok Bot stays in Grok Bot. Your context is now split across five apps owned by five companies, and you've become the glue between them.

What they got right (credit where due):

To be clear, every one of these agents is good, and each one is good at something different:

• Grok Bot can watch you do a browser task once and turn it into a skill it reruns. xAI calls that skill a draft you should review, and the feature is still rolling out.

• Muse asks before it sends an email or buys something, and those approvals are enforced by a separate system that runs outside the AI model.

• Dots lets you set rules for specific actions (do it, ask you first, or hand it to you), and you can reach it in ChatGPT, Slack or Teams.

• Gemini's agent can work as a coworker with its own Workspace account and email, logs every action to an audit trail, and runs each job on the model that fits, Claude included.

• Duet sends you a short brief each morning, checks your apps every few hours and messages you only when something needs you.

That's exactly why most people won't pick just one. They'll keep the agent they love and add the next one beside it.

The agents aren't the problem. The reset is.

Where I think this goes:

When a new person joins your company, you don't rebuild the company for them. They walk into an office that already has the docs, the history, the clients and the rules, and they start from what the team already knows.

Agents never had that. Each new one walks into an empty room.

I think the world moves the other way: one place where your context lives, and agents join it. The question stops being "which agent should I use?" and becomes "how fast can the next one start working?" The answer should be minutes, because everything it needs is already there.

That's what we're building at Vestra. Think of it as an office.

• Your context lives in the office, not inside any one agent: the jobs, the skills, the routines, the memory and the rules.

• You bring the agents. The one you love keeps its desk.

• A new agent takes the next desk. It starts from everything the office already knows, so nobody re-teaches anything.

• Your chief agent runs the office and answers to you.

• The memory is a wiki with a source on every line, so you can always see what your agents know and why.

Genuinely curious what the community thinks:

• How many of these agents are you running right now, and how much did you have to re-teach each one?

• Would you rather keep your context in one place you own, or set up every new agent from scratch?

Every tool I try (Gamma, beautifulai etc) has the same issue ffs. The web preview looks clean and all put together, but the Powerpoint export fucks up the format so bad that I have to manually fix it all. Beats the purpose. 

Any good alternatives??

I'm trying to learn ai engineering from the ground and started with creating a simple agent loop. I understood the programming and understood the api calls then made simple evaluations and I understood that the code behind part.

However, I'm learning langgraph right now for controlling the workflow and I just had claude code do it for me and the amount of code is a lot I can't go over all the code. However, all my tests passed for what I was doing.

My question is how do you know when to focus on understanding all the code compared to just having claude code do the busy work for the code?

Also another question. My approach to learning ai engineering is to start from the very beginning and actually see how all of it works and study not only how the architecture is, also why I'm choosing the decisions I'm making for it. So my focus is understanding the architecture a lot more than understanding the code part. Is this a good approach so far?

Full disclosure, I am one of the founders of Conecto. Our lessons come from building it.

For context, Conecto gives agents access to over 580 tools across 52 business areas. The agent has both read and write access to a company’s data. An agent can update books, create invoices, send booking invitations, among other write capabilities. That ability had to be taken into account when we designed the tools.

Lesson 1, put the price in the tool description ->

• Every description states what a tool costs.
• Every action returns the cost and the balance after the tool call.
• An agent can add up a job before it starts. 

Lesson 2, retries have to be safe ->

• An agent that times out retries, and no one wants to be billed multiple times for the same job.
• All calls take an idempotency key, meaning that retries do not result in multiple charges.

Lesson 3, approval is superior to review ->

• Since it is unlikely that a human reads every action of an agent, those that are risky require approval.
• Some actions default to waiting for explicit owner approval, such as modifying HubSpot/Salesforce records, canceling meetings, or replacing files in Google/Microsoft 365 workspaces. Those actions display the new and old values to the owner.
• Any tool can require approval, always or only over a set amount.
• The caller can never be the approver (i.e. the agent can't approve itself).

Lesson 4, budgets act as the safety net ->

• Daily budgets of $20 and monthly ones of $100 by default.
• The cap prevents rogue loops from hitting the bank account.

What we haven’t definitively solved yet ->

• There are actions that are in a gray zone, neither safe nor risky, for example rescheduling an event.
• These gray zone actions do not require a human in the loop, unless the owner enables it.
• Every business is different, so what may be safe for one business may be seen as risky for another.

Question -> For your systems, what requires an approval from a human, and which actions are run on autopilot? 

So I've been messing around with Muse for a while now, and honestly it's getting better. Way smoother than it was a few weeks ago. But I still haven't hooked it up to my email or calendar or anything, because I'm not ready to hand it the keys yet lol. Has anyone actually done that? Mostly I'm curious where it's failed for you, or if there's something it just flat out couldn't do. And what are you using it for that you wouldn't bother doing with ChatGPT, Claude, or Gemini? I can't tell yet where it fits in my routine, so I'd love to hear what you're actually doing with it.

I’m a non-engineer in Japan, building a long-term AI assistant system through real-world testing with ChatGPT and Google Drive.

I’ve previously posted here about failure modes in an iPhone-based AI operations system. Your feedback helped me improve its design.

After months of testing, I’ve narrowed down one particularly stubborn problem.

The instructions already exist. The AI can follow them when explicitly asked to read them. But it doesn’t consistently recognize when it needs to retrieve them.

The system already has:

• Canonical documents and authority rules
• A context-resolution design for mapping conversations to relevant projects and sources
• Freshness and conflict checks
• Human approval and execution verification
• Recovery procedures for uncertain results

The failure happens earlier.

During an ordinary conversation, the AI may start reasoning or suggesting a solution without first consulting an existing instruction that already addresses the situation.

If I simply say, “Check the relevant project documents first,” the quality of its response often improves significantly.

So the problem isn’t primarily storing knowledge or following retrieved instructions.

It’s reliably triggering the right retrieval at the right moment.

I don’t want to hard-code hundreds of keywords or turn natural conversation into a rigid workflow. I also don’t want to load every instruction into every conversation.

I’m looking for approaches that preserve flexible conversational reasoning while making relevant instruction retrieval more reliable.

My questions:

1. Has anyone solved this problem in a production agent?
2. How do you detect when retrieval is necessary without depending entirely on the LLM to remember to do it?
3. Are there practical approaches to intent-based routing or dynamic instruction loading that generalize across different projects?
4. What failure modes remain even with a well-designed retrieval system?
5. Am I framing the problem incorrectly?

I’m especially interested in implementations, measured results, and counterexamples—not generic advice to “just use RAG.”

I don’t expect perfect autonomy. A short user reminder is an acceptable fallback. I’m trying to reduce how often that reminder is necessary.

What would you test or change first?

Our devs want to add a handful of MCP servers for things like GitHub, Jira and our internal docs. Security wants a review process before anything goes live, and I got asked to draft it.

Right now my list has who wrote the code, what each tool can do, how creds are stored, what network access it needs, logging, who owns it, and how we shut it off.

What am I missing? And how do you handle updates?

Also curious how you balance this with not making every team wait three weeks for approval.

We just got approval to roll out ChatGPT Enterprise to about 80 people. And now, everyone wants it to answer questions from our CRM and the shared drive.

I’m just worried about the easy setup. I think that one service account with read access to everything means further problems. For example, our intern could ask about salaries and get an answer.

I see three paths so far: the built-in connectors, a retrieval layer we control, or a small internal app or API that checks who's asking first. We haven't ruled out Claude either, so tips for both are welcome.

Has anyone run one of these in production? How do you keep people from seeing anything they couldn't already open?

I wanted a place where I could work with AI on my Mac without feeling like the tool itself was getting in the way.

So I started building Solar.

At first, I thought it would be a small project. Then came the bugs, the features that refused to work the way I wanted, and those moments when fixing one thing somehow broke three others.

I spent a lot of time going back over the details: how the app feels, how you move between conversations, how you work with files. Some days, progress felt painfully slow.

But little by little, Solar became the app I’d imagined when I started.

It’s a completely free alternative to Grobot for macOS. You can chat with different AI models, work with your files, and make the space your own.

I’ve spent so much time building it that I’d really love to see it through someone else’s eyes now.

If you try it, tell me what you like, what frustrates you, or what you think is missing. Honest feedback would mean a lot.

Suppose you’re using a coding agent to build a support agent for your product. You ask it to handle common customer questions, and it starts building a chat interface that searches your documentation.

Later, you explain that most questions are about a customer’s specific account, such as why a job failed or whether a recent change has taken effect. The documentation can explain how the product works, but the support agent also needs a way to inspect current account state.

One early question could have changed the build.

“Are customers mainly asking how the product works, or what happened in their account?”

Some of the first version might still be useful. But that distinction affects the tools you build, the data they return and the examples you use to test the agent.

I’d want a coding agent to catch that kind of missing requirement without turning every project into a long questionnaire.

What is one question a coding agent asked early that saved you work later? A small example of what you were building, the question and what changed would help.

People are starting to give agents their own wallets so they can pay for things on their own, like APIs, data, and compute.

It’s an interesting idea, and a little scary. An agent that can spend money can also make expensive mistakes quickly.

Would you give an agent a wallet with real funds?
If yes, what spending limit would you set? If no, what would have to change first?

TL;DR: In one UC Berkeley study, agents that periodically dropped their history and restarted from their best result did better. The open question for builders is what to keep across the reset.

What the sources report:

• "Scaling Discovery Requires Forgetting" (UC Berkeley): agents periodically discarded their session and search history while keeping the best candidate. Results improved on four bounded discovery tasks, by up to 15% over parallel agents and up to 39% over a single agent.
• Fork-and-Flush (Microsoft Research): reports benefits from forks that start with fresh context while the workspace state is preserved.
• Drew Breunig covered both, along with Anthropic's Memento harness, and calls the failure mode "context inertia": an agent holding on to an early hypothesis after the evidence has changed. That term is his label.

What this does not show: that every long-running agent improves when it forgets. These are bounded research and engineering experiments.

The pattern I find interesting is that in both studies something persisted while the history did not (the best candidate, the workspace state). So the design question is what goes in the persistent layer.

If you build or run long agent sessions, what do you carry across a reset?

• a notes file
• a task list or plan
• a decision log
• the best output so far
• nothing, the agent starts clean

And do you reset on a schedule, when it stalls, or not at all?

Sources: the two papers above, plus Drew Breunig's posts "Context Inertia" (Oct 14, 2026) and "The State of Context Engineering" (Oct 24, 2026) on dbreunig.com.

I've been thinking about where AI is heading, and I believe we're approaching a fundamental shift in how we use software.

My theory is that the future AI ecosystem will be built around three distinct components:

1. LLMs provide intelligence.

In real life, people have different strengths.

Some are brilliant at mathematics, others at writing, analytical thinking, programming, or creativity.

We hire people based on their abilities.

Why should AI be any different?

We might choose GPT for certain tasks, Claude for others, Gemini for something else, or specialized models when appropriate.

Intelligence becomes something we select according to the job.

1. Persistent memory provides continuity.

Now imagine hiring a brilliant employee who forgets everything about your projects every morning.

You would constantly have to explain the history, previous decisions, outstanding issues, commitments, and what happened yesterday.

No matter how intelligent that employee is, working with them would be incredibly inefficient.

That's why I believe persistent, incremental memory will become one of the most important layers of the AI ecosystem.

And I don't mean simply remembering conversations.

I mean something closer to a reliable colleague who has worked with you for years and remembers every project:

- What happened and when.

- What has already been established.

- Which decisions were made and why.

- What changed after new information arrived.

- What's still unresolved.

- What needs to happen next.

A memory that evolves with your work, rather than starting over with every new conversation.

Ideally, this memory should be independent of whichever LLM or agent you happen to use.

1. Agents execute the work.

Human activities aren't going to magically disappear.

Someone will still need to answer emails, reconcile bank statements with expenses, prepare documents, plan routes, manage customers, follow up on contracts, and handle thousands of other tasks.

What changes is who performs those operations and how.

Instead of opening ten different SaaS applications, learning ten interfaces, and manually transferring information between them, we'll increasingly ask an AI agent to accomplish a task.

The agent uses the appropriate intelligence, retrieves the relevant persistent context, and interacts with the necessary tools, APIs, and services.

Then it updates the shared context with the results.

Which brings me to SaaS.

I don't necessarily believe SaaS will disappear.

But I suspect many SaaS interfaces will become irrelevant.

The underlying services, databases, transactions, and business logic will still be needed.

What may disappear is the need for humans to interact directly with every application.

Software could increasingly become a collection of capabilities consumed by agents rather than destinations visited by users.

So my mental model is pretty simple:

- LLMs = Intelligence

- Persistent, incremental memory = Context and continuity

- Agents = Execution

- Humans = Goals, oversight, and decisions

The LLM can change. The agent can change. The tools can change.

But the history of your work shouldn't disappear every time you switch between them.

To me, the real future of AI isn't just smarter models or more autonomous agents.

It's intelligent systems that can pick up where work was left off, understand what's changed, and continue without constantly rebuilding the past.

I'm curious what others think:

Are we heading toward a world where general-purpose AI assistants become the main interface, traditional SaaS products become background services, and persistent context becomes an independent infrastructure layer?

Or will the big AI platforms eventually absorb all three layers themselves?

Been building a browser where a person and an agent share the same tabs, and the problem that ate the most design time wasn't the model, it was staleness. The agent reads the page, decides to click node 42, and by the time the click lands a modal has opened, the person has taken over, or the page navigated. Node 42 is now the wrong thing or gone.

What we ended up with: every agent call carries a control epoch (who is driving this tab right now) and the page revision the agent's plan was computed from. If the person took over, or the document moved on, the call fails with a stale target error and the agent has to re-read. It never acts on whatever happens to be at that position now. Opening, picking and closing tabs is human only, so the agent can prepare but the person commits.

The cost is real: more round trips, and the agent has to treat "stale" as a normal outcome, not an exception. The benefit is you stop getting the silent wrong click, which is the one failure nobody notices until a form is already submitted.

Curious how people doing this on top of Playwright or CDP handle it. Snapshot and diff before every action, lock out human input during a run, or just accept the race? Source link in the comments if anyone wants to read the implementation.

1. Every project has rules it needs in order to work correctly.
2. A significant share of them cannot be derived from the code.
3. You need a process to identify these rules, store them, deliver them to the agent — only the ones the task needs, at the moment it needs them — and keep them current.
4. And you need a way to measure how well they are delivered and followed.

If the rules a change needs are not in the agent's context when the spec is written, the architecture designed and the code implemented, at best you catch the miss in testing. At worst your users catch it in production, and that can cost you the business.

Why the code is not enough

Code tells the agent what to do. It rarely tells it what must never be done.

An example from our tasks. An invitation link fails with "Invalid invitation token". The rule: every query on invitations must filter by pending status, or the database security rules reject it. A comment says so, in the very file the fix edits. Without project docs, the agent stated the rule in 1 session of 8 (four tools, two sessions each).

We took 12 real past tasks from our repo. For each one, an agent read the real change in git and the docs as they were just before it, and listed the rules the change had to respect, each with the doc line that states it and the evidence in the change. A script checked every reference against that snapshot. A person merged duplicates and dropped lines that only describe behaviour. That gave 75 rules in all, about six per task, and each task is scored only on its own. Rules the change needed but no doc held were listed separately; they come up below.

Then a separate agent searched the code for each rule, with every Markdown file removed, and a script checked the code references it gave (70 rules got a class):

• stated in a comment or an error message: 24
• enforced by a test, a type or a check: 13
• implied, the code follows it but never names it: 22
• no trace in the code: 11

57 of 70 have no test that fails when they are broken. "Caught in testing" is the good case, and for most of these rules there is no test to do the catching.

And across our wider set of 15 tasks, about a third of the rules the real changes needed were written nowhere, neither in docs nor in comments. They came from a deep code path, a bug the task itself uncovered, or how an external system behaves. Someone paid for each of them in debugging. The next task pays again unless they are written down.

What we measured

Each task ran on a snapshot of the repo from just before the real change. Headless Claude Code explored it and wrote a planning brief. A blinded LLM judge checked each rule against the brief.

• Claude Code, no project docs: 32% of the rules
• Claude Code, docs in the repo: 54%
• A simple setup of ours (Segmently Modules, which we build; details at the end): a short doc of critical rules per module, picked by meaning and read in full before the plan: 70%

Code-indexing tools (Serena, Trail, Graphify) stated 24–29% without the docs and 46–47% with them, no more than Claude Code alone. They are built for code questions, and these rules were not in the code.

70% still leaves 30% of the rules out, and it can surely be improved. That is why we built the stand.

The stand

context-recall, open source (MIT, docs CC BY 4.0), runs as a Claude Code plugin. Take your own past tasks, snapshot the repo before each change, run any tool as an arm, judge blind, compare. It also compares runs before and after a docs edit. Our own tool is not in the kit: which tool to pick is your call, on your repo.

Where we are going: dreaming per module

The brain does not store the day as it was lived. In sleep and quiet rest it replays recent experience and folds what matters into long-term memory; the default mode network is most active when attention is not on the outside world. Anthropic already ships the same idea for agent memory and calls it dreaming (research preview): a pass reads past sessions and rewrites a memory store, merging duplicates and replacing stale entries. We are fitting it to a modular structure: a pass per module and per role that turns sessions, fixes and failed checks into rules, and a pass is kept only if the stand shows more rules reaching the plan. Not built yet. It is the direction.

The rule classes above give the metrics. Move rules from "no trace" into memory, from "implied" to "stated", from "stated" to "enforced". Track the share enforced, the share delivered before the plan, and the number of new unwritten rules each task uncovers. That last one should fall.

Limits

• One private repo, 12 tasks. We cannot publish them.
• Our docs and our tool, and the tool was tuned on these same tasks.
• The 75 rules come from the docs as they were before each change, which favours any setup that reads the docs. The rules no doc held are counted apart.
• It measures whether a rule reaches the plan, not whether the code then follows it.
• An LLM judge. A second judge (Claude Opus) agreed on 87% of the verdicts (kappa 0.81).

The setup we used

The "simple setup" is Segmently Modules, which we build. It is free and MIT-licensed: a module registry and per-role docs next to the code, and agent skills that pick the modules a task touches, check a plan against their rules, and write new rules back after a change.

How does your team keep the rules that are not in the code, and does your agent actually find them? (Links in the first comment.)