A consultative team's most valuable knowledge surfaces where no sales tool is looking: in delivery work. An engineer pairing on a client's cluster hears about a compliance deadline months before it becomes a question anyone asks out loud. That observation could shape how the whole team helps this client. Instead, it dies in a project channel.
Mother Tree keeps it alive. A signal is not something to sell on, it is something to help with, and shared across the team it is where solutions come from. That is the shift the system is built for: adding value becomes a continuous group process instead of a one-person hunt.
In practice, it turns a delivery-side observation into knowledge anyone can use in the next client conversation, without asking delivery people to write CRM notes and without an agent acting on anyone's behalf.
The system has been in production at Aknostic, a European platform consultancy, since early 2026, and the code is open source (Apache 2.0). This account draws on our experience report submitted to ASISAS 2026, a workshop at ECSA 2026 on secure, intelligent, and sovereign agentic systems.
The problem: commercial memory that evaporates
In consultative work, the constraint is choreography, not volume. A platform consultancy runs a handful of multi-quarter client relationships, and the next conversation matters more than the next lead. What makes that conversation valuable is knowledge: what this client worries about, which beliefs they already hold, what our delivery people keep hearing. All of it existed, scattered across Slack threads and individual memories, where it helped no one.
The methodology came before the system. Mother Tree implements a doctrine we call the Mycorrhizal Method, named for Suzanne Simard's research on forest networks. Trees are linked underground by mycelium, the thread-like body of the fungi colonising their roots: the trees feed the fungus sugar, and the fungus moves water and nutrients between every root system it touches. Simard called the oldest and most connected trees mother trees, and they subsidise seedlings too shaded to photosynthesise their way out of the understory.
Both halves map. The mycelium is the database, the connective layer nobody owns, through which contributions move between people who never speak directly. The mother tree is what the system tries to be for a new joiner, who walks into an account they have never worked on and is subsidised by knowledge they did not gather. A consultancy's usual answer is to seat the new person next to whoever has been there longest. This one puts the subsidy in a database, where it survives that person taking a holiday, switching accounts, or leaving.
That gave us three properties any architecture would have to support: the shared substrate comes before the agents; reframes, the insight that changes how a client sees their problem, are first-class records; and conversations are structured sequences with named phases, so prep and debrief are structured too.
People participate in three roles. Hunters carry the conversation choreography, gatherers are delivery people whose first-hand client contact produces signals, and citizens are everyone else on a lighter twice-weekly curriculum. Everyone feeds the same memory and everyone draws on it. The system trains, preps, and debriefs all of them, and never acts on anyone's behalf.
The loop in practice: one observation, round trip
An ordinary Tuesday, anonymised. A delivery engineer writes in a project channel that the client keeps getting pulled into compliance timelines: "they're worried about NIS2." The Spotter recognises a signal, the Weaver structures it as a regulatory concern of high urgency, and the Archivist writes it to the shared database, where its embedding lands near an existing insight whose reframe argues that sovereignty and cost reduction aren't competing board priorities but the same initiative.
Weeks later, a hunter has a meeting with that company's CTO. Two business days before, the calendar-sync job queries the database by vector similarity, and the prep message surfaces the March signal, names the resonant worldview, and points at the reframe. Three business days after, the debrief asks what was confirmed, rebutted, and new. The answers become signals the next ingestion incorporates.
Notice what didn't happen: nobody sold anything. A delivery engineer noticed a worry, and weeks later a colleague walked into a meeting knowing how to help with it. The loop closes on vector similarity, not on anyone writing a report. The gatherer doesn't need to know the hunter exists; the hunter doesn't need to know the gatherer wrote anything. The database accumulates the conversation between them.
The database is the product
Every persona, prompt, training piece, and briefing reads from one PostgreSQL database, produces text, and writes back. The personas are replaceable workers around it. The schedule decides what happens next; the agents get called when it does. The substance lives in commercial-intelligence tables (change statements, audience worldviews, personas, competitors, insights, and signals), each carrying a vector embedding, so semantic similarity is the primary read pattern.
Marketing content enters through scheduled ingestion, history through captured signals and structured debriefs. When the group process needs it, an agent adds that information to the conversation: information, not an agenda.
The always-on layer is a set of declarative Kubernetes CronJobs:
| Job | Cadence | What it does |
|---|---|---|
| Foundation ingestion | weekly | Classifies marketing-surface documents into foundation records, context-aware |
| Narrative ingestion | daily | Extracts consultative reframes, evidence, and triggers, anchored in those records |
| Discipline | weekly / monthly | Weekly pipeline review, monthly retrospective, account-review polls |
| Calendar sync | daily (weekdays) | Emits meeting prep two business days before, debrief three days after |
| Pulse | every 5 minutes | Due reminders, stale threads, pipeline nudges, expired enrollments |
| Training delivery | daily | The next training piece per enrolled user, by role, stage, and chapter |
| Embed-backfill | scheduled | Generates embeddings for any record that lacks one |
There is no message queue and no DAG runtime: the cron schedule plus PostgreSQL is the orchestrator.
The interactive layer is a Slack bot, with an operator CLI reaching the same data through the same API. Nine personas sit on top: three conversational (Seth for positioning, Lawrence for consultative diagnosis, Mother Tree as the integrative default voice, with a Trainer routing between them) and the rest operational (the Spotter, Weaver, and Archivist from the loop above, a Pulse that works out whose turn it is, and a Dispatcher). Each has one prompt, one model, one responsibility.
A frontier model with persistent memory owns private state. Our substrate has no owner and is read-write by many scheduled processes. Any agent can be swapped without losing memory. The memory cannot be swapped without losing every agent at once.
Architecture notes, for the engineers
PostgreSQL 17 with pgvector, run by the CloudNativePG operator. The schema is exposed as a typed GraphQL API through PostGraphile ("the schema is the API"). Embeddings come from BGE Multilingual Gemma2 at 3584 dimensions, and cosine similarity drives training-source selection, briefing assembly, deduplication, and profile merging at an 85% similarity threshold.
Why choreography beats autonomy for a collective tool
We evaluated the usual agent frameworks (CrewAI, LangGraph, AutoGen) for two weeks and stepped back. The objection was never to the frameworks, which are competent software, but to their programming model as the basis for a collective tool. Their operating burden, on top of the system using them, did not pay for itself in our setting.
Two properties matter most when an agent's output enters a substrate other people rely on, and an autonomous loop handles both weakly. Auditability: every record carries its source document and the run that produced it, and every LLM call has a named entry point in the codebase (extract, score, triage, arbitrate, character_respond) with a fixed prompt template and input contract, so when something goes wrong three months later the trace is in the database rather than in an agent's working memory. Boundedness: an autonomous agent calls tools as many times as its reasoning decides, and cost becomes a probability distribution. A system ingesting hundreds of documents a week and running a thousand pulse cycles a day wants budgets that survive a quarterly forecast.
So the system runs on five conventions:
- Workflows are scheduled, not driven. No agent decides when to run; the cron does.
- LLM calls happen at known points. The LLM is a function with a stable signature, not an agent with a goal.
- Multi-judge scoring replaces self-evaluation. Covered in its own section below.
- Writes are reversible. The substrate snapshots and restores via operator-run commands.
- Idempotency is enforced at the data layer. Similarity checks before insertion, deduplication by thread and content. Running anything twice is, by construction, identical to running it once.
Three costs come with that. The system cannot improvise: an unclassifiable document falls through to a default extractor, and a human writes the new pipeline. Latency is right-time, not real-time: the five-minute pulse is the unit of attentiveness. And throughput is bounded by the schedule, though the substrate still accumulates faster than anyone can read it.
Others have argued the same: Anthropic recommends "simple, composable patterns" over complex frameworks, and most production agents turn out to be "background jobs wearing a chat interface". It is the argument we make about platform governance too: design the evidence into the deployment path and auditability falls out by itself.
The proof run: 944 → 303 → 189
The architecture didn't survive contact with real data unchanged. Our first ingestion run returned 944 foundation records from 289 source documents, hundreds of them near-duplicates differing only in surface phrasing.
The fix was context, not a bigger model. We rewrote extraction to be context-aware, giving each document the existing records in its prompt so it could suppress duplicates, and reran on the same input. LLM-driven consolidation then merged what remained:
| Stage | Result |
|---|---|
| Source corpus | 289 documents |
| First extraction run | 944 foundation records |
| Context-aware extraction, same corpus | 303 records (a 68% reduction) |
| After LLM-driven consolidation | 189 records |
Persona records fell from 28 to 9, competitor records from 67 to 17. None of that came from swapping models. We have been suspicious of model-only benchmarks since.
Quorum admission: how records earn their way in
Fewer, better records still need a gate. In a collective system, a plausible-but-wrong record propagates: everyone who draws on the substrate inherits it.
Every candidate insight is scored 0–1 by three independent open-weight judges: Devstral 2 123B, Llama 3.3 70B, and Gemma 3 27B. The decision is by quorum, not by mean:
| Condition | Outcome |
|---|---|
| minimum score ≥ 0.7 | All three agree: auto-accept |
| maximum score ≤ 0.4 | All three agree: auto-drop |
| spread ≥ 0.3 | Judges disagree: escalate to Claude Haiku 4.5 triage, which may defer to Sonnet 4.6 arbitration or flag the record for human review |
This is LLM-as-judge used for production admission, deciding whether a record enters the substrate other processes trust, rather than for evaluating output quality. It is the smallest defensible alternative to a single model scoring its own work.
A narrative-extraction run over our corpus produced 816 scored insights: 815 cleared the quorum, 1 was flagged, mean judge confidence 0.87.
Why we do not trust that number yet
A 99.9% auto-accept rate could mean the system is well-calibrated, or it could mean three judges trained on overlapping data agree on plausible-but-wrong records while lenient thresholds wave them through. Our corpus is also single-voice: one organisation's marketing repository. The panel guards against single-model bias; it does not guard against judge collusion.
The next trust investment is a reviewer-facing queue that samples auto-accepted records against human judgement: three votes plus a human spot-check.
Freedom to operate: the model map and the withdrawal test
We use freedom to operate as a practical complement to sovereignty: if a dependency disappeared tomorrow, which choices about this system would we lose? A system has freedom to operate when the answer is "few enough to continue." That question, not a flag, decided where each model runs:
| Role | Model | Provider | Class |
|---|---|---|---|
| Bot conversation & persona responses | Qwen 3.5 397B | Scaleway | Open weight, EU |
| Light extraction & classification | Mistral Small 3.2 24B | Scaleway | Open weight, EU |
| Embeddings | BGE Multilingual Gemma2 | Scaleway | Open weight, EU |
| Multi-judge scoring (3×) | Devstral 2 / Llama 3.3 / Gemma 3 | Scaleway | Open weight, EU |
| Signal extraction & structuring (Spotter, Weaver), consolidation | Qwen 3.5 397B | Scaleway | Open weight, EU |
| Deep extraction | Claude Opus 4.6 | Anthropic | Closed, US |
| Message triage & judge-disagreement triage | Claude Haiku 4.5 | Anthropic | Closed, US |
| Judge arbitration & opt-in premium conversation | Claude Sonnet 4.6 | Anthropic | Closed, US |
The split follows measured quality, and it has already moved once in open weights' favour. The Spotter and Weaver originally ran on Claude, because no open-weight model we tested held up at the false-positive rates single-message classification demands. They have since moved to Qwen on Scaleway: the substitution the design was built to allow, executed. Deep extraction stays on Opus 4.6, where Qwen produced thinner reframes and looser schema adherence. Every Anthropic call is named, and every one has been swapped before without architectural change.
Deployment matches the map. Everything runs in one Kubernetes namespace on a Scaleway cluster: Flux CD reconciling from the repo, GitLab CI building images with kaniko, SOPS-encrypted secrets, CloudNativePG backing up continuously to object storage in Paris, and inference through Scaleway's OpenAI-compatible Generative APIs. Data at rest, in backup, and in embeddings stays on European infrastructure, the same posture as our CI/CD. The named Anthropic calls are the only traffic that leaves, and whether that counts as a residency violation is a data-classification decision, not a system-level claim. (Mother Tree is developed with Claude Code, but that is upstream tooling, not the deployed runtime.)
By the withdrawal test, Mother Tree continues without US frontier inference, at the quality cost named above. The design buys four properties:
- Data residency by construction, with the Anthropic boundary named and classifiable per deployment.
- Model optionality. The core relies on the OpenAI-compatible API shape, so swapping providers means one base URL and one set of model identifiers.
- No autonomous-loop lock-in. With no agent runtime, the system inherits no runtime's view of which models support tool use or structured output. The inference layer is just a function call, so the orchestration choice turns out to be a dependency choice.
- Cost predictability. Open-weight inference is priced per token and each cron tick has a known budget, so provider switches are arithmetic rather than forecasting.
Freedom opens that list and cost closes it, deliberately: ownership is negotiating leverage.
Where it stands
The always-on layer has run since early 2026; active end-user use began 14 April 2026. The first 30 days, to 13 May: four enrolled users (one hunter, three citizens), 109 signals captured from channel chatter, 237 Slack interactions, four weekly reviews, one monthly retrospective, 62 contacts across 64 companies, and one bug that misrouted weekly deliveries to the wrong Slack account, since fixed. This is a small deployment in its first weeks.
Security posture, stated plainly
Authorisation on the GraphQL surface is currently a shared secret, with user-level authorization enforced one layer up. There is no PostgreSQL row-level security. SSRF protection on external URL fetches and adversarial-input testing against the bot are known gaps on the roadmap.
Three lessons generalise beyond sales. Methodology-first scales architectural decisions: when a new model ships, the question is whether it serves the methodology better than the current one, and without that doctrine every model release is a refactor. Choreography is auditable in a way autonomy is not: the trace lives in the database, and the state that doesn't exist yet is a column away. And the value compounds with the number of people using it, because the memory that prepares each person is built by all of them.
Try it, or talk to us
Mother Tree is open source: fork it, run the patterns against your own workload, and tell us where they break.
And if the withdrawal test raised a question about your own stack, talk to us. Running that test across an organisation's dependencies is exactly the work we do.