Personas, Tools, and Teams That Talk to Themselves
Posted on
A pattern essay. The follow-up to The Reflexive Advisor Team — lifting the general shape out of the specific net, so you can see Agentic-Nets as a substrate for designing teams of personas, not just clever pipelines.
From one agent to a working team
Give a chat agent tools and it gets sharper. Give it more tools and it gets faster. Then you keep going, and somewhere around the tenth tool you notice the agent is good at operating but bad at being. It has no role. No lane. No teammate to defer to. It is one head holding everything, and it forgets what you told it last week.
That ceiling is structural, not a prompt-engineering problem. One agent is, by definition, one role. The moment your work spans more than one domain — health and finances, planning and coding and QA, gathering and analysing and publishing — “stuff more into the prompt” stops scaling. You don’t need a bigger agent. You need a team.
Chat agents are great for exploration. Agentic-Nets are what you use when exploration becomes production work.
That’s the point of the runtime: **Agentic-Nets give you a substrate to design personas — agents with tools, memory, and a lane — that interact with each other to advise you or to work as a self-organising team toward a goal.** The reflexive advisor team I wrote about last week is one specific instance. The pattern underneath it is the actual story.
Governed multi-agent runtime. Your agents stop running naked.
What a persona is, in net terms
A persona, in this world, is not a sticker on a prompt. It is a structural object made out of net primitives. Spelled out:
Persona ingredient
Net primitive
Identity, focus, guardrails
per-persona p-*-config place — focus, tone, what’s off-limits, edited as data
Memory across sessions
p-*-journal place — event-sourced tokens, not prompt-stuffed history
Capabilities
tools available to the agent transition, gated by role flag (r---- … rwxhl)
Knowledge of the user
shared p-about-me place every persona reads
Where it speaks
p-*-output place; everything it says is a token, queryable, replayable
What it can call
tool nets it invokes via INVOKE_TOOL_NET — peer consult, search, code execution
Every line of that table is a real piece of the graph, addressable from outside. The config is a token — change the persona’s tone or guardrail without redeploying anything. The journal is a token stream — replay the persona’s last fortnight and ask what it remembered when it answered. The role flag is enforced at tool dispatch, not in the prompt — so an r---- advisor can read everything in the runtime and cannot, by construction, write or execute. The lane is real.
The point is short: a persona is a region of the graph, not a paragraph in a prompt. That’s what makes it inspectable, replayable, and re-usable across nets. A persona you build for one team can be deployed inside another with its journal intact.
How personas talk to themselves
A team isn’t just N personas in proximity. Four mechanisms turn loose agents into something that behaves like a working group, and each one is a real piece of net structure — not a prompt convention, not a chat handoff, not a string the LLM made up.
Peer consult (synchronous). When one persona’s domain bleeds into another’s — career sees a finance dimension, health sees a mind dimension — it doesn’t simulate the other persona inside its own prompt. It calls the other persona for real. A tool net wraps the peer as a fire-on-demand callable; the consulting persona invokes INVOKE_TOOL_NET, the call blocks until the peer responds with a correlation-ID-tagged result, and the consulting persona weaves the answer in with an explicit attribution line: “Mind notes that…”. The contract is strict — one consult per firing, only across the directed pairs that make sense.
Hallucination isn’t prevented by prompt engineering; it’s prevented by the graph.
Fusion (asynchronous). Multi-domain questions used to fragment into N parallel chatbots. With fusion they don’t. The coordinator emits a p-pending-fusion token alongside its routing decisions, 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 — until either the expected count lands or a timeout kicks in. Then it composes one paragraph that pulls all domains together, attributes each one, and ends with a synthesized takeaway. Two domains. One answer. Auditable.
Shared board (state). Some context belongs to the whole team. A p-team-board place holds short briefs every persona reads on every reply — recent reflections, ambient knowledge, what the others noticed yesterday. A real teammate at standup. The board is just a place; “team awareness” is a query against it.
Scheduled reflection (autonomous). This is the one that turns a Q&A pipeline into a team. Each agent transition can carry its own schedule directly on its inscription — schedule.type is interval or cron, and the runtime AND-gates schedule eligibility with token availability. A scheduled transition with no consume preset fires purely on time. A scheduled transition with consume presets fires only when both the schedule and the input tokens line up. Standups, rollups, insight crystallization — they happen between user turns, on the runtime’s own clock.
You go to bed. The team meets. You wake up to advisors that are noticeably smarter than yesterday’s.
These four mechanisms are the difference between N parallel chatbots and a team.
Two modes: advisors vs self-working groups
The same building blocks compose into two recognisable team shapes.
the shared persona-team skeleton
p-inbox / p-goal
user message OR goal token
t-intake (MAP)
normalize, copy to staging
p-staging
+ p-about-me, p-team-board
t-coordinator (AGENT)
router · fans out
persona A
config + journal + tool nets
persona B
config + journal + tool nets
persona C
config + journal + tool nets
persona D
config + journal + tool nets
t-fusion (AGENT) → p-final-output
waits on p-pending-fusion · attributes each domain
t-*-standup (scheduled, optional) · cron / interval directly on the inscription
turns advisor mode into a learning team — turns self-working mode into a self-correcting one
Mode A — Advisor team (reactive). A user asks. The coordinator routes. Personas reply. Fusion answers. Reflection improves the team between turns. The user is the loop’s pacemaker. Example: life-advisor. The team exists to give the user better answers over time. Output is advice, not action.
Mode B — Self-working group (proactive). A goal token enters. Personas execute their roles. Handoffs flow through the graph. The user supervises but doesn’t pace. The schedule and the work itself drive the loop. Examples: agile-team (PM → Architect → Developer → QA → DevOps, doing real coding work via command transitions running Claude Code) and intel-gather (nine cooperating nets crawling, classifying, crystallising, publishing). Output is artifacts — code, articles, decisions, deployments — not just text.
The distinction is who paces the loop, not the underlying primitives. Same skeleton. Two drives.
This is what the public README has been promising the whole time. Look at the bullet list:
– Virtual developers with explicit permissions, memory, and execution boundaries.
– Virtual agile teams where planner, builder, reviewer, tester, and releaser agents coordinate through nets.
– Smart development tools that behave like reusable nets instead of throwaway prompts.
– Product-level systems where backlog, QA, docs, incidents, and operations communicate as structured nets.
Mode B is that bullet list, made literal.
Three teams, one skeleton
**life-advisor (advisor mode). Six nets in one model. A coordinator that routes user questions to four domain personas (health, finances, career, mind), peer-consult tool nets between the directed pairs that make sense, a fusion agent for multi-domain answers, and a net-reflection whose five transitions carry their schedule directly on the inscription — twice-daily standups produce reflections and a team-board, then a synthesizer crystallises a small set of durable cross-domain insights every advisor reads on the next reply. The full walk-through is in the previous post. The structural detail worth noting here: no daemon, no tick token.** Master is the clock; the schedule lives in the field.
**agile-team v5.2 (self-working). Five nets — PM, Architect, Developer, QA, DevOps. PM is the sole user interface; everything routes through it. Coding is real, done by command transitions that invoke claude -p against a working directory, with QA running tests and DevOps deploying. The structural detail worth noting: validator+enricher MAPs at every persona handoff.** LLM agents are lossy — they forget fields, hallucinate paths, leave shapes broken. Between every two personas sits a deterministic MAP transition that re-fills missing fields from a config place (forcing workingDir to config.workspaceRoot, defaulting testCommand, repairing the token shape) before the next persona ever sees it. The graph repairs lossy LLM output between turns. The agents stay sharp because the MAPs cover for them.
**intel-gather v2.4 (self-working, large).** Nine cooperating nets — Source Gatherer, Feed Monitor, Content Analyzer, Knowledge Crystallizer, Custodian, Forum Monitor, Trusted Sources, Guardian (Wachter), Publisher. The team gathers raw signal, classifies it, deduplicates it, crystallises insights, verifies against trusted sources, and publishes articles through a Claude-Code-driven pipeline into a blob store. The structural detail worth noting: **the Guardian net is a meta-persona** — its job is not to do the work, but to watch the other personas, evaluate goal progress, and emit corrective actions back into the graph. A team that watches itself, with a teammate whose lane is the team.
These three sit on the same skeleton. They differ in scale (4–9 personas), in pacing (user-paced vs schedule-paced), and in tooling (consult tool nets vs command executors), not in shape.
The general recipe
If you want to build your own persona team — advisor or self-working — here is the eight-step skeleton. Every step maps to a real Agentic-Nets primitive.
Pick the personas. Three to nine roles with genuinely non-overlapping lanes. If you can’t write a one-sentence guardrail per role, the lane isn’t real yet. Combine the roles you can’t separate.
**Give every persona a p-*-config place.** Focus, tone, guardrail, what’s off-limits. This is your prompt, but as data — editable without redeploying the transition.
**Give every persona a p-*-journal place.** Tokens, not strings. Replayable. The persona’s memory is event-sourced state, not a stuffed prompt.
Add the shared p-about-me place every persona reads. Optionally add a p-team-board for ambient cross-persona context. These are the “the team knows about you” and “the team knows what the team is doing” surfaces.
Add a coordinator/router. An agent transition that decides which persona(s) to fan out to. Use CREATE_TOKEN for routing decisions — emit.when rules don’t reliably evaluate against agent output. Coordinator decides; the graph routes.
Add a fusion step if more than one persona can answer at once. Track expected reply count on a p-pending-fusion token. Time-out if everyone doesn’t make it. Attribute every domain explicitly in the fused answer; that’s what keeps the output auditable.
Decide who paces the loop. User-paced = advisor team. Schedule-paced = self-working group. Put the schedule directly on the transition inscription — interval for “every N hours”, cron for clock-time triggers. The runtime AND-gates schedule with token availability, so a scheduled transition with consume presets fires only when both the clock and the inputs say yes.
Add tool nets for cross-persona consult. One per directed pair you want synchronous. Deployed-but-stopped, fire-on-demand. Inside each persona’s prompt, give it the strict contract: only consult when truly useful, only inside the right pair, only one consult per firing.
Once these eight pieces are in place, you don’t have a workflow. You have a team.
Closing
A persona is a region of the graph, not a paragraph in a prompt. A team is the structure between those regions, made into real arcs and tokens and schedules. Once you see it that way, “multi-agent” stops being a marketing word and becomes a question about graph topology.
The advisor team gives you something a single agent can’t — a counsel that defers, attributes, and gets sharper between meetings. The self-working group gives you something else a single agent can’t — work that runs without you, with deterministic repair built into the handoffs. Same skeleton. Different drive.
This is what pattern crystallization — repeated AI-assisted steps become reusable deterministic automation; cost curve bends — looks like at the team level. The MAPs that repair the agents’ output, the schedules that pull standups out of the chat loop, the journals that replace prompt-stuffing with replayable state. Each one started as a thing the LLM had to do every turn. Each one, eventually, became a piece of the graph.
Petri nets carrying the structure. Agentic-Nets carrying the intelligence. The graph carrying the team.
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, sketch your three-to-nine personas, give them config and journal places, point a coordinator at them, and run a tick.
The team will meet you there.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
