Blog · 2026.10.06
Redrawing the loop map with three cores
Elanous calls a worker that comes back to the job it was given at set times a “loop agent.” Those workers multiplied one or two at a time, until one morning we opened the map and found more than twenty registered loops, eight of them switched on. The scheduled-job lines numbered over a hundred. That same morning one loop had fired the same job eight or nine times over, and another job had stalled because there were no hands to delegate it to. Building one more loop was not the answer. This post walks outside developers through a design that redraws that map around “three cores” — and, cell by cell, separates what actually runs today from what is still planned.
루프 에이전트 지도, 셋으로 다시 그리기 — 코어 셋 · 등급 셋 · 동사 일곱, 그리고 무엇부터 만드나.
Beta — until the general release, Elanous is provided as is (Apache-2.0). Get news of the general release at elanous.ai.
What had become complicated
The problem was not the number of loops but their size. Each loop owned a single job, so every new loop brought its own ledger and its own state. And loops read each other’s ledgers directly. The paths for passing context around grew not in step with the number of loops but closer to its square. In practice, the ledgers that loops read from one another had branched into more than nine strands.
The same request also took a different path depending on which door it came through. From a messenger it went through a card to one loop; from the issue tracker, to another loop; from the terminal, down yet another path. Four paths mean four places to fix — and four places to ask “why did this job run twice?”
Finally, nothing separated what is “Elanous itself” from what is “a bundle for a particular line of work.” Dozens of scheduled jobs for specific tasks sat in the same list as the jobs that keep Elanous itself healthy. In that state there is no way to decide what to install for someone setting it up for the first time.
Three cores — big roles, and hands spun up as needed
The design’s first decision is not to slice loops finer but to give out big roles. Two agents are resident, and one kind of agent is spun up each time there is work.
| Core agent | What it does | How many |
|---|---|---|
| Coordinator | Takes requests from every door · classifies them with a scoring rubric · sets priorities · picks which contract will handle each one · hands out tasks · reconciles progress · writes the morning briefing | Resident, 1 |
| Task worker | Takes one task and carries it from plan → build → wrap-up (review, landing, checking the real result). Recurring work arrives the same way, as a “recipe task” | N as needed · exits when done |
| Guardian | Looks after Elanous’s own body · observability and health · credential and token renewal · usage limits · backup checks · the outgoing-message queue · watching for leaked secrets | Resident, 1 |
Whatever is not an agent stays as substrate; agents just read it and write to it. That means one board holding releases and tasks, a task card holding the context of a single task, a contract that states what is taken on and how it will be judged, a recipe as the template for recurring work, the harness as the hands that actually touch code, and observability.
Context follows three rules.
- Context lives on the card. A task’s original request, goal, run record, things to fix and next move are kept on that task card and nowhere else. A task worker reads and writes its own card alone.
- Decisions live on the board. Assignments and priorities exist on the board, and the coordinator is the one who writes them. A task worker reports just two things to the board: “done” or “a person needs to look.”
- People live in the channel. What reaches a person is the coordinator’s briefing and decision cards — nothing else. Loops do not talk to each other directly.
This way each agent reads from two places: the board and its own card. With N agents there are 2N paths. And whatever the door, there is one path — the coordinator receives the request, classifies it once, picks one contract and hands it to one task worker. There is a memory layer underneath as well; this post just notes that it exists.
With a single coordinator, the worry is what happens when it stops. The plan is not “never dies” but “cheap when it dies.” The coordinator keeps no state of its own; all state lives on the board. Tasks that have already been handed out run to the end on their own cards, without the coordinator. If the coordinator stops, new assignments stop — the work does not. Whether it is alive is measured not by “is the process up?” but by “when did it last write to the board?” If the model in charge of its judgment stops responding, it steps itself down to assigning by rubric scores alone, and says that it did so in the first line of the briefing. Everything in this paragraph is Planned — not yet.
Three tiers — core · standard · market
| Tier | What | Can it be switched off? |
|---|---|---|
| Core | Coordinator · task worker · guardian · board · cards · observability · harness | No. This is Elanous itself |
| Standard | Default contract bundle (development · screens · documents · operations) · default recipes (watching · morning briefing · weekly report · document generation) | On and off, recipe by recipe |
| Market | Optional packs — investment signals · video and ads · lecture notes · field records · industry knowledge packs | Install and remove |
The key point is that market packs do not spin up more loops. A pack registers contracts and recipes with the coordinator, and that is all; the actual work is done by task workers. If a pack truly needs something resident, it is allowed a single resident process, watched by the guardian. That bar is set by a number too: just when, over the past seven days, that schedule actually produced work at least half the time.
The bundle depends on the user. Someone installing for the first time gets the three cores, the default recipes and one starter contract. On the first run Elanous asks a single question — “What kind of work do you do?” — and, based on the answer, picks one of marketing, field work, education, management or general. Developers who contribute to Elanous add a “contributor pack” on top (our release procedure, gate rules and repository conventions). Power users who work across several machines layer their own contracts and graphs on top of that.
There is one judgment we revised here. The first draft moved “making things (implementation)” into a developer pack. Looking again, that was the wrong direction. Whether you are a marketer or a teacher, the most useful thing right now is to “make” tools, automations and dashboards just by saying what you want, and to “run” them right away. So implementation stays in everyone’s default, and what moves into a pack is just what you need when contributing to Elanous itself.
The default is seven verbs, not job roles
Investing, R&D, marketing, development — build a separate loop for each kind of work and the map gets complicated again. So we made the default the “verbs” you reach when you break work all the way down. There are seven.
| Verb | What it does | What counts as “done” |
|---|---|---|
| ① Watch | Keeps collecting news · industry trends · markets · papers · repositories | Ran on schedule · duplicates removed · digest delivered |
| ② Research | Question → sources → counter-evidence → report | Cited sources and a summary |
| ③ Decide | Scoring · options · recommendation · decision card | Scores and reasons · a decision record |
| ④ Make | Code · documents · spreadsheets · content · video · experiments | A file or pull request · preview and gates |
| ⑤ Act | Things done in the outside world — sending · scheduling · deploying · operating a browser or terminal | An execution record · reading back what was sent |
| ⑥ Check | Did it really happen, and how did it turn out? | Tests · read-back · tracking results |
| ⑦ Remember | Keeps the result for the next decision | A retrospective record |
A job role is a difference in “which order the verbs are chained in, and what is known.” Development is ② research → ④ make → ⑥ check → ⑤ act (landing) → ⑦ remember. Investing is ① watch → ③ decide → ⑤ act → ⑥ check → ⑦ remember, and ⑤, where money is at stake, always goes through a human approval card. Marketing is ① watch → ② research → ④ make → ⑤ publish → ⑥ check results → ⑦ remember.
Two things cut across all seven, and the core is responsible for them. One is the safety gate: money, anything irreversible, and security always go up to a person as a card. The other is context — the cards and the board described above.
Each verb already has material that runs inside Elanous every day. A scheduled intake gathers trends every morning (①), the morning briefing goes out, and the harness turns a one-line request into a pull request and carries it through review and landing (④⑥⑤). But today these are “separately built scripts and graphs,” so they cannot share verbs with one another. Making the verbs the default folds those separate pieces into “contracts and recipes.” That folding is the body of this design, and it is still Planned — not yet.
Our hypothesis is this: if a federation of loops chains the seven verbs without a break — from making through acting and checking — and runs it so that every step is visible as an execution graph, work will reach the end without a person attached at every step. Whether that holds is what we measure as we build in the order below.
What to build first — dependencies first, scores within each phase
There is one principle for the order: a later phase cannot run without the one before it. For the coordinator to hand out work there have to be hands, and for the hands to pass context along there have to be cards. So the phases go substrate → hands → coordination → guardian → market core → tiers. The scoring rubric (axes such as value, effort and risk) is used just for ordering items within a phase. A rubric cannot capture dependencies, so an item from an earlier phase goes first even when it scores lower.
And retirement comes after proof. An old loop is switched off after — and not before — we have confirmed that the new one, running as a shadow, did the same job on the same day.
Each phase has a check that decides when it is done.
- P1 Hands — Hand it any five tasks. Each must end either with no human help, or by “asking a person, with the evidence attached.” At least half of the five are tasks that are not development.
- P2 Coordination — Run the coordinator as a shadow next to the old loops. The old loops are switched off when every job they fired falls within what the coordinator would also have fired.
- P3 Guardian — The scattered operations jobs fold into a single guardian schedule, and the existing alerts go out on the same day, in the same numbers.
- P3b Market core — In an empty project that is not the Elanous repository, hand over ten requests: two each of research, deliverables, actions, monitoring and decision support. If the one way a task can end is “pull request merged,” it does not pass this check.
- P4 Tiers — A new install starts the three cores and nothing more, and the scheduled jobs of work packs drop out of the core list.
P3b has its own phase for a reason. In a few places, today’s core still assumes that “Elanous builds Elanous.” The board is shaped like our release checklist, the target repository is our repository, and work ends as a merged pull request. Outside users do not run Elanous; they run their own projects. So the board widens to a general shape — project · goal · milestone · task — and the ways work can end widen to code · deliverable files · research reports · operational actions · content. Working in other repositories is experimental: elanous harness say --target <path> picks the target repository, but the supported scope is not settled yet (we confirmed once that a child agent wrote a document in a local project outside Elanous).
What works today / what does not yet
| Item | Status |
|---|---|
| One-line request → plan · build · gates · unattended review · landing (the harness) | ✅ Works today |
The harness taking a repository outside Elanous as its target (harness say --target <path>) | ⚠️ Experimental — confirmed once · supported scope not settled yet |
| Watching loop runs as a live graph (the web app’s Live tab) | ✅ Works today |
| Individual loops such as scheduled intake · morning briefing · landing repair · draft cleanup | ✅ Running — but for now each runs on its own |
| Role-based loops | ⚠️ Running in shadow mode (results are not written outside) |
| Gathering context onto task cards and a single board | 🔲 Planned — not yet |
| Task worker (spun up, exits when done) | ⚠️ Partial — the decision and execution code is in; wiring it into the real flow is the next step |
| One coordinator for every door · the “cheap when it dies” design | 🔲 Planned — not yet |
| Folding operations jobs into the guardian | 🔲 Planned — not yet |
| Completion evidence for the seven verbs · starter contracts · the first-run question | 🔲 Planned — not yet |
| Splitting core · standard · market tiers · installing market packs | 🔲 Planned — not yet |
We are also writing down, ahead of time, the numbers we will measure once the plan is done: three resident loops, two places where each agent exchanges context, and one path for any given request. Today those are more than ten, more than nine strands, and more than four. Whether these numbers go down is how we will judge whether the map really got simpler.
Instead of building more loops, we are shrinking the map. Each time a phase is passed, we will write about it again — together with the record of what actually ran.
Source: github.com/ElanvitalAI/elanous · Docs: docs.elanous.ai
Beta — provided as is (Apache-2.0). Get update news at elanous.ai. Read also Watch the agent think.