A walk-through of building a six-net, self-learning life-advisor system on AgenticNetOS where the agents reflect, talk to each other on a schedule, crystallize shared insights, and fuse multi-domain advice into one answer — all between your questions, while you’re not looking.
The problem with a single agent
You can ask a single chat agent for advice. It will give you advice. It will be confident. It will not remember what you told it last week. It will not notice that the question you’re asking today contradicts the situation you described in last Tuesday’s session. It will not push back when you ask the wrong domain expert.
Chat agents are great for exploration. Agentic-Nets are what you use when exploration becomes production work.
The “agent runs naked” problem shows up the moment you start asking life questions:
- “Should I take the angel round?” — a finance question on the surface, a career-strategy question one layer down, a stress-tolerance question another layer beneath that.
- “How should I plan my week?” — useless without knowing whether you’ve slept four hours a night for two weeks.
- “Why am I so anxious?” — a mind question in the asking, a body question in the answer.
These aren’t questions for one agent. They’re questions for a team — and a team that talks to itself between meetings.
Today I built that team on AgenticNetOS. Six nets, twice-daily standups, durable shared insights, synthesized multi-domain answers. Here’s how the layers stack.
The architecture, in three layers
The system is a single AgenticNetOS model called life-advisor containing six nets:
The three layers:
- Q&A layer — coordinator routes each user message to one or more domain advisors. Each advisor uses its own journal, can synchronously consult one designated peer through a tool net (career↔finances, health↔mind), and emits a reply.
- Fusion layer — when a message routed to two or more advisors, a synthesizer agent waits until all the expected replies arrive, then fuses them into a single answer with explicit per-domain attribution and a synthesized takeaway.
- Reflexive layer — on a schedule (twice daily by default), the team holds a standup. Each advisor reflects on its own journal and recent sibling reflections, posts a short brief to a shared team board, and writes a fuller reflection to its private log. Then a separate agent crystallizes the team board into a small set of durable cross-domain insights that every advisor reads on every subsequent reply.
You go to bed. The team meets. You wake up to advisors that are noticeably smarter than yesterday’s.
Layer one — domain advisors with peer consultation
Each advisor is a small, focused net: an inbox place, a staging place, an intake-MAP transition, an advisor-AGENT transition, a private journal, a per-advisor config, and an output place. The agent reads:
- the user’s message
- a shared about-me profile blob (your goals, constraints, preferred tone)
- a per-advisor config (persona, focus, guardrails — e.g., the health advisor’s guardrail is “do NOT give medical specifics; refer to a doctor”)
- its own journal (last 5 entries)
- the last 3 entries from each sibling advisor’s journal — for context only, not to advise outside its lane
When the message has a clear angle inside another advisor’s domain — career sees a finance dimension, health sees a mind dimension — the advisor can call its designated peer through a tool net. That tool net wraps the peer advisor as a synchronous, fire-on-demand callable. The agent invokes it via INVOKE_TOOL_NET, the call blocks until the peer responds with a correlation-ID-tagged result, and the originating advisor weaves the peer’s perspective into its final answer with an explicit attribution line: “Mind notes that…”.
The contract is strict: only one peer consult per firing, only when truly useful, only inside the right domain pair. The result is an advisor that feels less like a chatbot and more like a teammate who knows when to pull in a colleague.
A real reply, generated today, after a question about sleep and anxiety:
“Alex, tonight try cooling your sleep environment by lowering the thermostat 2-3 degrees — cooler temperatures promote deeper, more restorative sleep. Mind notes that when anxiety spikes tomorrow, practice brief breathing exercises to reset your nervous system and reframe anxious thoughts as ‘this is just fatigue talking’ rather than reality.”
The health advisor framed the answer. The mind advisor’s contribution sits inside, attributed and integrated. Hallucination isn’t prevented by prompt engineering; it’s prevented by the graph — the peer-consult is a real, audited round trip, not a paragraph the LLM made up about another role.
Layer two — fusion, with explicit attribution
Multi-domain questions used to surface as multiple separate reply tokens — health here, career there, fend for yourself. Now the coordinator emits an extra pending-fusion token alongside the routing tokens, recording the request id and how many advisors it expected. A fusion agent watches the raw reply pool and waits — re-queuing itself with an attempt counter every poll cycle — until either the expected count is matched or a timeout pushes it to fuse what it has.
When ready, the fusion agent composes one paragraph that pulls all domains together, attributes each one, and ends with a synthesized takeaway.
A real fused answer, generated today, after “My anxiety is creeping up and v1.0 is slipping. What’s the smallest move I can make today to break the cycle?”:
“From a career perspective, pick one small, completable task from your v1.0 checklist that you can finish in under 30 minutes — like fixing a single bug or writing one section of documentation. When anxiety spikes, remind yourself this is likely fatigue-related cognitive impact rather than actual project risk. From a mind perspective, do a 2-minute box breathing reset: inhale 4 counts, hold 4, exhale 4, hold 4 — repeat 5 times while rolling shoulders back to immediately lower cortisol and break the anxiety feedback loop. The key synthesis: combine the physical breathing reset with focused task completion — use the breathing exercise to calm your nervous system, then channel that clarity into tackling one small, achievable task to break through paralysis and build momentum.”
Two domains. One answer. Concrete protocol. The attribution lines aren’t decorative — each clause is traceable back to a real advisor token in the raw reply pool. You can audit it.
Layer three — the reflexive part
This is where the system stops being a clever Q&A pipeline and starts being a team.
A new sixth net, net-reflection, holds five agent transitions: four standups (one per advisor) and one insight synthesizer. They aren’t triggered by the user, by tokens, or by any external clock. Each transition carries its own schedule directly in its inscription, and the runtime fires them when the schedule says so. No tick token, no fanout, no daemon — just the field.
The schema is small: schedule.type is either "interval" or "cron", and the runtime AND-gates schedule eligibility with token availability. A scheduled transition with no consume preset (only non-consuming reads) fires purely on time. A scheduled transition with consume presets fires only when both the schedule says yes and the input tokens are present. That AND-gate is the right semantics for any real “scheduled but not redundantly so” pattern.
Each advisor’s standup transition reads:
- its own journal (last 10 entries)
- its own past reflections (last 5)
- the last three reflections from each of the three sibling advisors
- the recent team board (last eight briefs from the whole team)
…and produces two outputs: a fuller reflection in its private log, and a one-to-two-sentence brief on the shared team board so the rest of the team can read what it noticed.
Then the synthesizer agent reads the recent team board (last 30 briefs) and the previous insight snapshots (last 5), and writes a new insight snapshot — a small set of three to six durable cross-domain truths the team has agreed on. The snapshot supersedes the previous one. Old snapshots stay on disk for audit; only the latest is read by the advisors on every subsequent user reply.
The first crystallized snapshot, generated today after a single tick — distilled from eight team-board briefs:
1. Sleep quality is the primary health leverage point — poor sleep triggers next-day anxiety and cognitive impact across all domains.
2. User maintains strong financial runway preservation mindset, requiring sustainability validation before any expansion decisions.
3. Career momentum is actively managed through structured morning deep work but remains energy-dependent.
4. Mind domain engagement is minimal with insufficient journal data to identify mental state patterns.
These statements weren’t in any single message. They emerged because four advisors looked at four different slices of the same person, then a fifth agent synthesized what the team agreed on. The fourth insight is honest about its own limitations — the mind advisor said so on the team board, and the synthesizer didn’t paper over it.
This is pattern crystallization — repeated AI-assisted steps become reusable deterministic automation; cost curve bends. The advisors no longer need to derive these patterns on every reply. They read them, apply them, and stay in their lanes.
The next user query, asked right after that snapshot crystallized, returned this reply from the career advisor:
“Alex, focus on completing the critical path testing and documentation for your v1.0 release. Given your energy constraints from sleep challenges, tackle the most complex technical work in your morning peak hours when you’re freshest, and reserve afternoon for lighter tasks like final packaging and deployment prep.”
The phrase “energy constraints from sleep challenges” was lifted directly from insight #1. The career advisor is applying the team’s crystallized wisdom while staying inside its own domain — exactly the contract.
What this gives you that a single agent can’t
| Capability | Single chat agent | Reflexive advisor team |
|---|---|---|
| Domain expertise | simulated | real persona + per-advisor guardrails |
| Memory across sessions | brittle, prompt-stuffed | per-advisor journals as event-sourced tokens |
| Knowing when to defer | rare | explicit “this isn’t my domain” clause + peer consult |
| Multi-domain answers | one paragraph that flattens everything | fused reply with explicit per-domain attribution + synthesized takeaway |
| Learning between turns | none | scheduled standups + crystallized insights |
| Auditability | “the LLM said so” | every claim traces to a token in a queryable place |
| Cost curve over time | flat — every question pays full price | bends — durable insights replace re-derivation |
The cost-curve point is worth dwelling on. On the very first message the system sees, the advisors derive everything from scratch. By the third week — once the team has met forty-two times, accumulated several hundred journal entries, and crystallized ten or so insight snapshots — most of the heavy reasoning has already happened. The advisors are mostly applying the team’s accumulated wisdom rather than re-discovering it. Local Ollama, twelve seconds per reply, instead of thirty.
The graph carries the load that a stuffed prompt was carrying before.
The schedule lives in the transition
Each standup is one inscription. The schedule field is two lines:
{
"id": "t-h-standup",
"kind": "agent",
"schedule": {
"type": "interval",
"intervalMs": 43200000
},
"presets": { ...non-consuming reads of journal, sibling reflections, team-board... },
"postsets": { "reflection": ..., "board": ... },
"action": { "type": "agent", "modelId": "life-advisor", "nl": "..." }
}
That’s it. Master’s ScheduleGate checks the field on every poll cycle. For interval mode, it tracks last-fired-at in memory and lets the transition fire once the elapsed time exceeds intervalMs. For cron mode, it parses a six-field cron expression with Spring’s CronExpression and fires when the next trigger time has passed.
"schedule": { "type": "cron", "cron": "0 0 8,20 * * *" }
The five reflexive transitions fire on their own schedule. The other ten transitions in the system (the user-facing pipeline) have no schedule field, so they fire purely on token availability — same as any normal Petri net transition. The two regimes coexist in one model with no special configuration.
Want hourly pulses from one specific advisor? Change one number in one inscription and re-deploy that one transition. Want the team standup to wait until the user has been awake for an hour? Switch its schedule to {"type": "cron", "cron": "0 0 9,21 *"}. The architecture absorbs both edits without ceremony.
There’s no external scheduler, no daemon, no tick token, no fanout. Master is the clock — once your inscription has a schedule on it, the runtime is the thing that knows when to fire.
Closing
This isn’t a research demo. It’s six nets in one model, running on a laptop, advising me about my sleep and my company’s runway and the v1.0 push for AgenticNetOS itself. It catches things a single agent never would. It improves on a schedule I don’t have to manage. It explains its synthesis with attribution so I can audit it.
What started as “I want a personal advisor” turned into a small, governable, self-improving team. Petri nets carrying the structure. Agentic-Nets carrying the intelligence. The graph carrying the wisdom.
Governed multi-agent runtime. Your agents stop running naked.
If you want to play with the same architecture, the open-source bits live at github.com/alexejsailer/agentic-nets — gateway, executor, vault, CLI, chat, blobstore. The closed-source core (node + master + GUI) is at hub.docker.com/u/alexejsailer. Pull the public compose, write your own about-me profile, and run a tick.
The team will meet you there.