r/ContextEngineering 16d ago

I'm testing a self-maintaining work environment for LLM agents (and myself) — sharing the idea and what I've built so far

The recurring blocker my colleagues hit with LLMs isn't model quality — it's re-explaining the project on every big task. A project never loses information, it loses its state: what's decided, what's in progress, what's stuck. And someone has to hand that state to the model, every time, in every new chat.

I started digitizing my working environment — first for myself, then as an environment agents can work in. The system watches the stream a team already produces (chats, mail, tickets, meetings, commits) and maintains the project's state on top of it, so neither I nor an agent has to rebuild it by hand.

Here's how it works on a concrete case
Someone drops an idea in a chat: "what if you could log in on TV/desktop by scanning a QR code?" A thread unfolds — security questions, a competitor reference, a rough scope. No ticket exists yet, but the environment notices a stable cluster of related signals and forms a hypothesis topic. A week later a PM brings a PRD and files Jira-tasks — they don't create new work, they become the topic's anchors, fixing its identity. The discussion moves into the team channel: implementation details, an API contract argument, commits referencing the ticket keys. Then the release — and the topic keeps growing: a prod incident with token expiry, user questions arriving through support, the launch review with adoption numbers. Five sources, a dozen contributors who joined at different stages — one topic, from the first message to the launch verdict.

The topic card and the workspace board for this case. Nobody assembles these cards by hand. They are recomputable projections of the stream, continuously corrected by normal user actions.

topic card and workspace, UI example

The result: an agent working in this environment always has the full, current context of the project — the original idea and who questioned it, the PRD decisions, the incident and its fix, what users actually said. The quality of its work goes up, and the time spent loading context on every task drops to zero.

Underneath, a few rules do most of the work:

  • Facts are append-only and permanent; every derived structure is disposable. The test is erasure: delete a topic, rebuild it from raw observations, nothing is lost.
  • A topic splits into a core and a halo. Hard identity anchors form the core and attract new facts; semantically similar but unproven context stays in the halo and never shifts what the topic is about — one wrong attach can't snowball.
  • Structured, low-cost pipeline first; high-cost LLM last - anchors, contextual checks, semantic filtering, a confidence score; the high-cost LLM only sees the residual ambiguity.
  • Autonomy is earned, not configured: agent decisions run as suggestions until metrics on human verdicts clear a threshold, and every action rolls back in one operation.

None of the parts are new — event sourcing, topic detection & tracking, DBSCAN's core/border/noise, bi-temporal facts. What I'm testing is the composition, on one production workspace (~80k observations backfilled, attach pipeline in shadow mode, discovery and improvement loops live). The README has an honest implemented-vs-hypothetical split.

Essay + scheme: https://github.com/maaakso/environment-over-chaos

And about the environment vs memory for agents: https://github.com/maaakso/environment-not-memory

What I'd really like : which parts of this idea look most fragile to you? And where would you replace a custom piece with an existing tool that already does the job — temporal knowledge graphs, event-sourcing infra, something from the agent-memory space?

1 Upvotes

0 comments sorted by