The agent that does not forget you when the tab closes
Most chat agents are tourists. They answer your question, the conversation ends, and everything they learned about you evaporates. The next session starts from zero: same introductions, same context dump, same generic answers.
Genesis is the opposite. It is a conversational meta-agent that moves in. The first time you talk to it inside an AgenticNetOS model, it builds itself a home: memory places for who you are, a journal of every turn, a registry of everything it has built for you, a queue for long-running work, and a handbook it consults instead of guessing. From then on it lives with you in that model. It remembers your preferences because it wrote them down. It improves because it reviews its own work. And when you describe a problem, it does not just answer: it builds and starts a small running system that keeps helping after the conversation ends.
This article walks through a real session from this week, then unpacks the engineering that makes it reliable on a local model, and closes with the use cases this pattern unlocks.
A real conversation: from “help me with fitness” to a running coach
This is an actual session against a fresh, empty model on a Mac running Ollama. No setup, no configuration: the model was created in the GUI seconds earlier.
Turn 1. The user types: “could you help me with my fitness program?” Genesis reads its memory first (four quick queries: who is this user, what have I built, what did I learn), finds nothing yet, and answers like a person would: it offers to build a personal fitness specialist and asks four clarifying questions about goals, preferred exercises, equipment, and limitations. It does not build anything yet. The turn takes about 50 seconds.
Turn 2. The user answers: “i like to train 4 times a week and i like to work on my biceps chest and cardio i need to train my heart to become more stable.” Now watch the order of operations, because it is the heart of the design:
- First, it writes memory. Within 17 seconds a new identity token lands in its self place: trains 4 times per week, favorite areas biceps, chest, cardio, goal heart stability. Remembering means writing a token, not saying “noted”.
- Then it queues the heavy work. Twelve seconds later a build request sits in its build queue: “Build fitness specialist for 4-day weekly training focusing on biceps, chest, cardio with heart stability goal”. The chat turn does not block on construction.
- Then it replies. The user gets an answer in under two minutes, with the note that a personal specialist is being built in the background.
Meanwhile, in the background. A durable builder transition picks the request out of the queue seconds later. It does not improvise: it checks its academy of proven recipes, finds the Q&A specialist shape, fires the recipe with a correlation id, and patiently awaits the result. Seven minutes later a complete fitness net exists: an inbox place for questions, a reply place for answers, a knowledge place pre-seeded with the user’s profile, and an answer agent deployed and running. The builder writes its records (blueprint, registry row, lesson, journal) and files a review request.
Then the reviewer judges it. A second durable agent picks up the review request and uses the new net like a real user: it injects a realistic fitness question with a correlation id, awaits the answer, reads the event trail, and writes an honest verdict with evidence. In this session: pass, score 9, “net responded within 11 seconds with high-quality advice, correlation field properly echoed”. If the verdict had been weak, it would have filed a bounded improvement request back into the build queue.
Turn 3, later that day. The user asks: “so what is my fitness plan now?” Genesis reads its registry, finds the fitness net, reads its reply place, and delivers the full plan in chat: a 4-day split with Monday chest and biceps, Tuesday zone 2 cardio for heart stability, Thursday variation work, Friday intervals with heart-rate recovery focus, and rest days. The plan reflects exactly what the user said once, one day earlier.
The architecture in one picture
Everything in that picture is Petri-net native. Memory is tokens in places, not a vector store bolted on the side. The builder and reviewer are ordinary agent transitions, work-gated by their input places: they fire when there is work and cost nothing when there is none. The built specialist is itself a tiny net you can open in the visual editor, watch tokens flow through, and extend.
What it took to make this reliable on a local model
Genesis runs its reasoning on a local Ollama model, not a frontier API. Getting an open-weights model to behave like a dependable inhabitant took a 17-round test loop and produced four mechanisms worth stealing for any agent system.
1. Write contracts: enforcement beats hope
Smaller models skip trailing instructions nondeterministically. The same builder prompt produced all seven record tokens in one run and silently dropped the last three in the next. No amount of prompt engineering fixed it, so the platform now enforces it: an agent transition can declare requireWritesTo in its inscription, and the runtime rejects the agent’s DONE until tokens have actually been written to those places, listing exactly what is missing. Bookkeeping became a contract instead of a hope. Legitimate early exits stay possible: build-specific requirements only arm after the agent actually deployed something.
2. The academy: crystallization applied to building
The first time Genesis builds a kind of net, it works free-form and makes mistakes. But a proven shape gets frozen into an academy recipe: a tool net that stamps out that exact topology every time, with the inscription skeleton embedded and only the domain wording left to the model. The builder checks the academy first, fires the recipe with a correlation id, and awaits the result. This is the platform’s crystallization story applied to construction itself: AI reasoning for the novel case, deterministic replay for the repeated one.
3. Eyes and patience: claims need evidence
Genesis has an AWAIT_TOKEN tool: block until a token matching a filter appears, with a correlation field discipline so it waits for exactly the thing it fired. Combined with event-trail queries, this gives agents eyes. The reviewer does not read the net’s structure and declare it plausible: it sends a real question, waits for the real answer, and cites what it saw. The single most important persona rule that came out of testing: never claim an action you did not perform with a tool, and never claim success you did not observe.
4. The handbook lives in the net, not the prompt
Genesis’s playbooks (how to build, how to schedule, how to repair, how to await) used to live in its system prompt: 78KB per turn, every turn. Now the situational chapters are tokens in a handbook place, seeded at bootstrap. The prompt keeps a table of contents and one rule: read the chapter before acting on a matching turn. Prompt size dropped to 28KB, behavior stayed identical, and the backend became its own context manager. A pleasant side effect: since the handbook is just tokens, Genesis can eventually edit its own chapters as it learns, which is self-improving documentation in the most literal sense.
Use cases this pattern solves
The fitness coach is one instance of a general move: conversation in, running backend service out. The same session pattern has produced, in testing this week alone, a houseplant care expert and an espresso brewing specialist, each built, verified, and answering within minutes. The shapes that fall out naturally:
- Personal domain experts. Fitness, plant care, cooking, car maintenance: a net per domain, seeded with your profile, learning new facts about you into its knowledge place with every question.
- Assistants that actually remember. Tell Genesis once that you prefer short answers and metric units, and every future conversation starts from that identity token, in any conversation, after any restart.
- Scheduled routines, safely. Ask for a daily morning summary and Genesis creates a cron-scheduled transition, configured with a real schedule block, and deliberately leaves it stopped until you confirm. An unattended timer firing an LLM is the main accidental-cost burner, so the contract is: build it, show it, ask first.
- A repair crew for its own work. When something it built breaks (a wrong place name, a bad model reference), Genesis diagnoses the failing transition, repairs the inscription, restarts it, and re-tests with one awaited probe. The user reports a symptom; the agent fixes the infrastructure.
- Org memory that compounds. Every build writes a lesson. The reviewer’s verdicts become knowledge. Repeated shapes become recipes. The tenth net is built faster and better than the first, and you can read exactly why in the journal.
Honest limits, and what is next
On a Mac with a local model, a full build-and-review cycle takes 10 to 15 minutes of background time, and chat turns share one LLM lane with the builders, so heavy parallel use stretches latencies. The chat contract absorbs this (answer fast, build in background), but it is honest to say this is a workstation-class experience today, not a datacenter one. The discipline mechanisms above exist precisely because local models cut corners under pressure.
Next on the bench: proactive delivery of build results into the chat (today you ask and Genesis relays the reply place), a CLI-provider adapter so the same persona can run its reasoning on coding-tuned models, and letting the reviewer’s lessons graduate into handbook chapter edits, closing the loop on an agent that maintains its own documentation.
The deeper point stands independent of any single feature: an agent with a place to live, a contract for honesty, and the ability to leave running systems behind is a different kind of tool than a chat window. Genesis does not just talk about your problems. It moves in and builds the machinery that keeps solving them.