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.

The Graph Structure

Nodes — Distinct Capabilities

Each node in the graph is a runtime protocol. It is a self-contained capability that handles a specific class of situation. For a brand like TNKase, the graph has nodes for dosing questions, safety and efficacy questions, off-label requests, adverse event handling, pricing, emergency escalation, and more.

Each node carries:

• Behavior specification — exact instructions for how the agent responds when this node is active
• Activation criteria — the conditions that send the agent to this node instead of another
• Retrieval configuration — for nodes that use a document library, the parameters that control what gets retrieved and how much of it reaches the agent’s context
• Type — nodes are typed which means some produce fixed responses, some generate answers from retrieved documents, some branch into sub-cases, some trigger escalation actions
• The node type determines what happens next. A retrieval node retrieves documents and adds them to context before answering. A canned node sends a fixed response immediately. A branching node reads another detail from the conversation to pick the next path.

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 the Agent Carries

As the agent traverses the graph, it carries state. This is the context built up during the conversation. This includes:

• The full message history
• Which nodes were activated in prior turns
• What documents were retrieved
• What flags were set such as PII flag, adverse event flag, emergency flag

This state keeps multi-turn conversations consistent. The agent does not treat each question alone. It reads the current message with the full prior context, and that context affects which node it routes and how it responds.

‍
The Standing Layer — Nodes That Are Always Active

Above the protocol graph is a standing layer. These are instructions that run on every turn, at every node, no matter which path the conversation takes. This covers the agent’s persona, scope, compliance rules, and tone.

The standing layer applies everywhere, uniformly. The runtime protocols narrow and specialize within it.

The Graph Evolves

This is where Ather diverges from every conventional agent architecture.

The graph is not fixed after deployment. It is a living structure. Its node properties get updated by an optimization system that runs in the background, observing how the graph performs, identifying where it fails, and proposing specific changes.

How the Graph is Observed

Every traversal produces an observation. Each time a conversation reaches a node and a response is produced, an evaluator scores the result on five axes: if the right node was activated, if the right parameters were set, if the node’s behavior specification was followed, if the response was clinically useful, and if the length was appropriate.

These scores drive the next round of changes.

A compliance check also runs simultaneously. It is a binary gate that flags any response that violates the agent’s requirements, regardless of the score. If a path fails compliance, it is disqualified and this is non-negotiable.

How the Graph is Mutated

After each observation cycle, the system identifies which nodes are underperforming That includes scores below threshold, compliance failures grouped together, or routing edges that are too imprecise.

For each underperforming node, an optimizer reads the full history of that node. It reads every version of its behavior specification, every score it produced, every mutation that helped or hurt. It does not just use the latest version. It checks the whole trajectory and identifies the trend.

It then proposes candidate mutations. These are new versions of the node’s properties. A mutation might:

• Tighten the behavior specification so the node gives clearer instructions
• Rewrite the activation criteria to clarify which questions belong to this node
• Adjust the retrieval configuration to fetch more documents, filter more tightly and surface different content
• Add a conditional branch to split a node into sub-paths for different cases
• Merge two overlapping nodes into one with a dispatcher parameter

Each candidate changes one property of one node. The system makes multiple candidates per node each cycle. Each one addresses a different problem and tries a different fix.

How Mutations Are Validated

Candidate mutations do not go live graph automatically. Every proposed change passes through two sequential gates.

Gate one — regression testing. The candidate is evaluated against a targeted question set for that node. It must score meaningfully higher than the current version. It cannot lower any other node’s performance. A mutation that fixes one node by taking questions from another is rejected and cannot create compliance failures. About 28% of candidates pass this gate.

Gate two — canary evaluation. Candidates that pass gate one are tested against the current live node. They run on the full question set for that node, in realistic multi-turn sessions. The new version runs alongside the old one. If the new version performs worse, even slightly on compliance, it is rolled back. About half of gate-one survivors make it through.

Only changes that are clearly better across all relevant measures, with no side effects, get added to the graph.

The Graph Learns What Doesn’t Work

The system maintains a rejection history for every node. It records each candidate mutation that failed, why it failed, and what type of change it was. The optimizer checks this history before making new proposals.

This creates a learning across cycles. If a specific change, like making activation criteria for a compliance-sensitive node consistently causes failures, the optimizer learns to avoid that direction and tries something else. The graph not only improves, it also tracks which improvements work and which directions are dead ends.

If a node gets changed many times with no successful update, the system detects a ceiling. That means the node’s current form cannot improve with that type of change. Instead of making more failing candidates, it shifts effort to a different property of the same node, or parks the node and focuses on higher-impact targets.

The Topology Itself Can Change

Most optimization systems refine the parameters of a fixed structure. Ather also changes the topology of the graph itself.

If two nodes have highly overlapping activation criteria and consistently compete for the same questions, the optimizer can propose a merge. It combines both into one node with a dispatcher parameter that routes each sub-case. The merged node has one set of activation criteria for cleaner routing, and multiple internal branches to keep the specific behavior.

If one node handles questions that are too different for a single instruction set, the optimizer can propose a split. It creates a new node to own the sub-case. The original node gets sharper. The new node starts with its own specification.

If a node needs to handle a distinction it cannot make now, like IV dosing vs. subcutaneous dosing, the optimizer can propose a new parameter The agent reads that signal from the conversation and uses it to pick the right instruction path within the node.

These are not frequent changes. They are high-leverage interventions used only when text-level changes stop helping. Each topology change goes through the same regression and canary checks as any other mutation. It only gets added if it proves better.

What 30 Cycles Looks Like

On the TNKase agent, the graph ran 30 complete observe-mutate-validate cycles in one day.

Results from those cycles:

• 397 candidate mutations were proposed across all nodes
• 110 passed the regression gate, a 27.7% admission rate
• 56 were permanently promoted into the live graph, surviving canary at a 50.9% rate
• The graph’s nodes were mutated across four properties: behavior specifications (57 changes), activation criteria (25), node descriptions (22), retrieval configurations (6)

The nodes that received the most optimization were Smalltalk, Scientific Q&A, Transfer to Human and Off-Label Refusal. Their failure patterns still produced viable fixes. Nodes that stabilized early were Pricing and Reconstitution. They were already close to optimal, and the gate correctly rejected candidates that didn’t improve on it.

The most impactful changes did not come from rewriting whole nodes. They were surgical. Adding one exclusion clause to the Dosing node’s activation criteria fixed a routing conflict with Scientific Q&A. Tightening a compliance line in the Off-Label node removed a set of false positives and adjusting the Dosing node’s retrieval configuration made PI-only content show up more reliably.

Small, targeted, validated changes. Compounding across cycles.

Why This Matters

Precision scales with complexity

A fixed-prompt agent gets less precise as the domain gets more complex. More topics create more confusion, more edge cases, and more contradictions. The graph architecture reverses this. Each node handles a narrow scope, and routing precision is optimized separately for each one. Complexity is handled by topology, not by making a single prompt do everything.

Compliance is structural, not advisory

In a conventional system, compliance lives as rules in a prompt that the model is asked to follow. In the graph architecture, compliance is enforced at the gate as structure. A mutation that creates a compliance failure is rejected by the system, not by a reviewer reading outputs. The agent cannot drift toward non-compliance.

The graph knows your requirements

The initial graph is generated from your requirements document. Every node, activation criterion, and behavior specification links back to a requirement. When the optimizer proposes a mutation, it stays within those requirements. It cannot propose changes that would violate them. The requirements are the invariant that the graph evolves within.

Every state is recoverable

Every mutation is versioned, so any node can roll back to any prior state. If a cycle produces an unexpected regression in production, the system can restore the previous node version in seconds. Nothing is lost. The history is complete.

‍