From 7c4c429912b3131e6f385d94471c36997d3591dd Mon Sep 17 00:00:00 2001 From: Andrei Savu Date: Mon, 31 Aug 2026 23:21:53 -0700 Subject: [PATCH] Shorten the idea to its three claims The section ran 39 lines and 307 words before a reader met a function name. It made three claims and gave each one a paragraph and three bullets, so the bullets restated the paragraph above them. Each claim now has its bold lead and the argument under it, at 22 lines and 189 words. Both framings stay, as `CLAUDE.md` requires: agents wait for events, and the agent is the ownership boundary. Two sentences ran to 26 words against the 25 the writing rules allow. Both are two sentences now. --- README.md | 53 ++++++++++++++++++----------------------------------- 1 file changed, 18 insertions(+), 35 deletions(-) diff --git a/README.md b/README.md index b6e705b..0a38d81 100644 --- a/README.md +++ b/README.md @@ -5,41 +5,24 @@ A minimalist framework for ambient, always-on agents. ## The idea -**Agents should wait for events.** An agent built on a request loop knows -nothing between calls: when a deadline passes or a task completes, -something else has to notice and invoke it. Ambion inverts the loop: - -- Agents wait in a session, and every event enters it as a message — a - person speaking, a person walking in, a timer firing, a task completing, - a system reporting. -- A message activates exactly the agents it concerns. The rest stay at - rest. -- Cost follows events. An idle session costs nothing. - -**The agent is the unit of context engineering, and the ownership -boundary.** Building one agent is already this work: choosing its tools -and shaping their responses, disclosing context progressively, adding -guardrails and completion checks. The techniques hold because they serve -one domain. In a shared context window they collide — every change lands -in every domain's context — and the shared agent settles at a local -maximum, where no team can improve its domain without degrading another's. -Ambion draws the boundary at the agent: - -- One team owns one agent whole: domain, tools, instructions, model, - evals. -- Inside one agent every technique serves the same domain, so the - techniques compose. -- A team improves its agent on its own schedule. - -**Every agent that keeps growing arrives at multi-agent collaboration. -Ambion starts there.** When one context window stops holding the work, the -fix is subagents — a team, inside one engine, with no owners and no record -of how it works together. Ambion makes the team first-class: - -- Agents with owners, working in a workspace built for collaboration. -- An agent reads what a colleague did and calls that colleague in by name. -- The platform provides what they share: the session and the record. The - complexity lives in the composition. +**Agents should wait for events.** An agent on a request loop knows nothing +between calls. When a deadline passes or a task completes, something else +has to notice and invoke it. Ambion inverts the loop. Agents wait in a +session, every event enters it as a message, and a message activates the +agents it concerns. An idle session costs nothing. + +**The agent is the ownership boundary.** Choosing tools, shaping their +responses, disclosing context progressively, adding guardrails: these +techniques hold because they serve one domain. In a shared context window +every change lands in every domain's context. The agent settles where no +team can improve its domain without degrading another's. One team owns one +agent whole — domain, tools, instructions, model, evals. + +**Every agent that keeps growing arrives at multi-agent collaboration.** +When one context window stops holding the work, the fix is subagents: a +team inside one engine, with no owners. Ambion makes the team first-class. +An agent reads what a colleague did and calls that colleague in by name. +The platform provides what they share: the session and the record. ## The activation rule