The Core Idea

Most AI systems work as fixed pipelines. A message goes in, moves through a fixed sequence of steps, and a response comes out.

Ather agents work as graphs. They are networks of interconnected capabilities where the route depends on the conversation itself. No two conversations take the same path. The agent reads the situation and traverses the graph accordingly.

Ather’s graph also rewrites itself over time. The nodes get smarter, routing improves and the whole graph gets better with use, without manual updates.

What the graph is made of

Nodes: small, opinionated capabilities

A node is a self-contained “protocol” for a particular class of situation (product questions, safety, off-label requests, escalation, etc.). Each one has:

• Behavior: how to respond, what to include, what to avoid
• Activation criteria: what kinds of questions belong here (and what don’t)
• Retrieval settings (when needed): what to fetch, how much, and how to filter it
• A type: retrieval-based, fixed response, branching/dispatcher, escalation, and so on

Edges — Routing

The edges in the graph are defined by the activation criteria of each node. When the agent gets a message, it evaluates every node’s criteria simultaneously and routes to the node that best matches the intent.

This is not keyword matching. The agent looks at the full meaning of the conversation, including prior turns, and picks the node whose scope best covers the situation.

Edges are therefore probabilistic. They map conversational intent to node activation. Making those edges precise is a primary target of optimization. A poorly defined edge means two nodes compete for the same questions and the wrong one gets picked. A well-defined edge means the agent routes correctly every time.

State: what carries across turns

Ather keeps multi-turn conversations coherent by carrying state forward, including:

• the message history
• which nodes have already been activated
• what was retrieved
• safety/compliance flags (PII, adverse event, emergency, etc.)

‍
The standing layer: rules that always apply

On top of the whole graph is a standing layer: persona, scope, tone, and compliance posture that applies on every turn no matter which node is active.
‍

The Living Graph

Ather agents don't behave like a single prompt trying to do everything. They work like a living graph: a network of specialized capabilities that routes each conversation to the right place, carries forward what's happened so far, and improves through measured, versioned updates.

The core idea: every message is a routing problem. Instead of pushing inputs through a fixed pipeline, Ather decides, turn by turn, which capability owns the moment.

The unit of the graph is a node — a small, opinionated protocol for one class of situation: product questions, safety, off-label requests, escalation. Each node specifies how to respond and what to avoid, what kinds of questions belong to it and which don't, what to retrieve and how to filter it, and what kind of node it is — retrieval-based, fixed response, branching dispatcher, escalation. When a message arrives, nodes compete on fit. This isn't keyword matching; the agent reads intent in context and selects the node that best owns the situation. Routing quality comes down to well-written activation criteria and ruthless elimination of overlap between nodes — two nodes that both claim a question is a routing bug waiting to fire.

Coherence across turns comes from state: the message history, which nodes have already activated, what was retrieved, and any safety or compliance flags raised along the way — PII, adverse events, emergencies. And above the whole graph sits a standing layer of persona, scope, tone, and compliance posture that binds every turn regardless of which node is active. The node decides what to say; the standing layer decides what may never be said.

The graph is "living" because it doesn't freeze at launch. Every interaction is evaluated: did we route correctly, follow the spec, retrieve the right things, stay useful, keep the right length? From those evaluations the system proposes mutations — small, targeted edits to a single node property: tightening a spec, clarifying activation criteria, adjusting retrieval, adding a branch. No mutation ships on its own merits. It must clear two gates: regression testing on targeted question sets, and a canary evaluation running side-by-side with the live version in realistic sessions. Compliance is the one gate that doesn't trade: a change that fails it is rejected even if it improves every other score.

Sometimes the right fix isn't a better mutation but a topology change — restructuring the graph itself. Two nodes that keep stepping on each other get merged. A node covering too many unrelated cases gets split. A recurring distinction that keeps mattering — dosing form, say — becomes a routing parameter. These structural edits are higher-leverage, reserved for when prompt-level tweaks stop moving the needle.

This architecture buys three things. The agent stays precise as the domain gets messy, because complexity lives in the graph rather than in one giant prompt. Compliance is enforced by the process itself, so unsafe changes can't go live by accident. And because everything is versioned, you can always roll back — recovery is fast.

Why we call it “living”

The graph isn’t static after launch. It evolves through a tight loop:

1. Observe: each interaction is evaluated (did we route correctly, follow the spec, retrieve the right things, stay useful, keep the right length?)
2. Propose: the system suggests small, targeted edits: tightening a spec, clarifying criteria, adjusting retrieval, adding a branch
3. Validate: changes only ship if they clear two checks:
   • Regression testing on targeted question sets
   • Canary evaluation side-by-side with the live version in realistic sessions

Compliance is non-negotiable: anything that fails the compliance gate is rejected, even if it improves other scores.

‍

Why this architecture matters

• It stays precise as the domain gets messy: complexity lives in the graph, not in one giant prompt.
• Compliance is enforced by the process: unsafe changes don’t “go live by accident.”
• You can always roll back: everything is versioned, so recovery is fast.