可查詢的上下文圖譜用於審核 AI 決策

We've launched on Product Hunt

Building Context Graphs: How Pylar Captures the Decision Traces That Make AI Agents Autonomous

Hoshang Mehta

Building Context Graphs: How Pylar Captures the Decision Traces That Make AI Agents Autonomous

The debate right now is whether existing systems of record survive the shift to agents. The answer isn't about better data access—it's about capturing something that's never been captured before: decision traces.

Here's the distinction that matters:

Rules tell an agent what should happen in general ("use official ARR for reporting").
Decision traces capture what actually happened in this specific case ("we used X definition, under policy v3.2, with a VP exception, based on precedent Z, and here's what we changed").

Most enterprise software captures data, but not the decision-making process. When a support agent escalates a ticket, the ticket shows "escalated to Tier 3." It doesn't show that the agent checked the customer's ARR in Salesforce, saw two open escalations in Zendesk, read a Slack thread flagging churn risk, and then decided to escalate. That synthesis happens in their head. The decision trace is lost.

The problem: Agents need access to decision traces—the exceptions, overrides, precedents, and cross-system context that currently live in Slack threads, deal desk conversations, and people's heads. Without this, agents can't learn from past decisions, can't apply precedent, and can't become truly autonomous.

The solution: Pylar sits in the execution path where agents make decisions. Every query, every tool call, every data access creates a decision trace. When you persist those traces, you get a context graph—a living record of how context turned into action, making precedent searchable and autonomy possible.

This post explains how Pylar captures decision traces, why this matters, and how it builds the context graphs that will power the next generation of autonomous agents.

The Problem: Decision Traces Are Missing

When agents make decisions, they pull context from multiple systems, evaluate rules, resolve conflicts, and act. But the reasoning connecting data to action is never captured.

What Gets Lost

Exception logic that lives in people's heads: "We always give healthcare companies an extra 10% because their procurement cycles are brutal." That's not in the CRM. It's tribal knowledge passed down through onboarding.

Precedent from past decisions: "We structured a similar deal for Company X last quarter—we should be consistent." No system links those two deals or records why the structure was chosen.

Cross-system synthesis: A support lead checks the customer's ARR in Salesforce, sees two open escalations in Zendesk, reads a Slack thread flagging churn risk, and decides to escalate. That synthesis happens in their head. The ticket just says "escalated to Tier 3."

Approval chains that happen outside systems: A VP approves a discount on a Zoom call or in a Slack DM. The opportunity record shows the final price. It doesn't show who approved the deviation or why.

Why This Matters for Agents

Agents run into the same ambiguity humans resolve every day with judgment and organizational memory. But the inputs to those judgments aren't stored as durable artifacts.

Example: A renewal agent proposes a 20% discount. Policy caps renewals at 10% unless a service-impact exception is approved. The agent needs to:

Today, steps 1-4 might happen, but step 5—the decision trace—is lost. The CRM ends up with one fact: "20% discount." It doesn't show why it was allowed.

Why Existing Systems Can't Capture Decision Traces

The problem isn't that decision traces are hard to capture. It's that existing systems aren't in the right place to capture them.

Operational Incumbents: Built on Current State

Salesforce, ServiceNow, and Workday are built on current-state storage. They know what the opportunity looks like now, not what it looked like when the decision was made.

The limitation: When a discount gets approved, the context that justified it isn't preserved. You can't replay the state of the world at decision time, which means you can't audit the decision, learn from it, or use it as precedent.

Example: A deal desk agent approves a 15% discount. The opportunity record shows the final price. But it doesn't show:

The decision trace is lost because Salesforce only stores the outcome, not the process.

Warehouse Players: In the Read Path, Not the Write Path

Snowflake and Databricks are positioned as the "truth registry" layer. They have time-based views—you can query historical snapshots, track how metrics changed, and compare state across periods.

The limitation: Warehouses receive data via ETL after decisions are made. By the time data lands in Snowflake, the decision context is gone. A system that only sees reads, after the fact, can't be the system of record for decision lineage.

Example: A support agent escalates a ticket. The ticket data eventually lands in Snowflake. But Snowflake doesn't know:

The decision trace is lost because Snowflake sees the outcome, not the execution path.

The Structural Advantage: Being in the Execution Path

Pylar sits in the execution path where agents make decisions.

When an agent triages an escalation, responds to an incident, or decides on a discount, it pulls context through Pylar. The orchestration layer sees the full picture:

Because Pylar is executing the workflow, it can capture that context at decision time—not after the fact via ETL, but in the moment, as a first-class record.

How Pylar Captures Decision Traces

Pylar captures decision traces by instrumenting the agent execution path. Every query, every tool call, every data access creates a trace that answers: what data was accessed, when, why, and how did it influence the decision?

The Execution Path

Here's what happens when an agent makes a decision through Pylar:

Step 1: Agent calls a Pylar tool

An agent needs to check customer health before approving a discount. It calls get_customer_health(account_name="Acme Corp").

Step 2: Pylar executes the query

Pylar runs the query against the materialized view, joining data from Salesforce, product analytics, and support systems.

Step 3: Decision trace is created

Pylar captures:

Step 4: Context graph is updated

The trace is persisted and linked to:

What Gets Captured

1. Query Execution Traces

Every query through Pylar creates a trace:

2. Decision Sequences

When an agent makes multiple tool calls to reach a decision, Pylar captures the sequence:

3. Cross-System Context

Pylar captures what data was accessed from which systems at decision time:

4. Precedent Links

Pylar links decisions to similar past decisions:

Building the Context Graph

When you persist decision traces over time, they naturally form a context graph: entities the business cares about (customers, deals, tickets, policies, agents) connected by decision events (the moments that matter) and "why" links.

The Graph Structure

Entities: Customers, deals, tickets, policies, agents, data sources
Relationships: Decision events, data access, precedent links, policy evaluations

Querying the Context Graph

Once you have a context graph, you can answer questions that were previously impossible:

"Why did we approve a 20% discount for Acme Corp?"

"What precedent did we use for similar deals?"

"How did we handle similar service-impact exceptions?"

The Feedback Loop

The context graph creates a feedback loop that makes agents more autonomous over time:

Example: The first time an agent approves a 20% discount for a customer with health score 45 and 3 SEV-1 incidents, it requires human approval. The decision trace is captured. The next time a similar situation occurs, the agent finds the precedent, applies it automatically, and only flags for human review if the situation differs.

Real-World Example: Support Escalation Decision

Let's walk through how Pylar captures a decision trace for a support escalation.

The Scenario

A support agent needs to decide whether to escalate a ticket to Tier 3. The agent uses Pylar tools to gather context.

Step 1: Agent Calls Pylar Tools

Step 2: Pylar Captures Decision Trace

Step 3: Context Graph is Updated

The decision trace is linked to:

Step 4: Future Decisions Use Precedent

The next time a similar situation occurs, the agent can query the context graph:

Why This Matters: From Automation to Autonomy

The difference between automation and autonomy is learning from precedent. Automation executes rules. Autonomy applies judgment based on past decisions.

The Evolution Path

Phase 1: Human-in-the-Loop

Agents propose decisions, gather context, route approvals, and record traces. Humans still make the final call, but the decision trace is captured.

Phase 2: Precedent-Based Automation

As similar cases repeat, agents find precedents in the context graph and apply them automatically. More of the path can be automated because the system has a structured library of prior decisions.

Phase 3: Full Autonomy

The context graph becomes comprehensive enough that agents can handle most decisions autonomously, only escalating truly novel cases. The graph keeps growing because the workflow layer captures inputs, approvals, and rationale as durable precedent.

The Compound Effect

Every automated decision adds another trace to the graph. The graph becomes more valuable over time because:

Schema Overview

The context graph uses a hierarchical schema that traces from agent decisions to the data that informed them.

Key relationships:

Traceability: Every decision can be traced back to the agent run, the tools called, the data accessed, and the precedents considered.

Closing Thoughts

The next trillion-dollar opportunity in AI isn't better data access—it's capturing decision traces. The question isn't whether existing systems of record survive. It's whether entirely new ones emerge—systems of record for decisions, not just objects.

Pylar is uniquely positioned to build these systems because it sits in the execution path where agents make decisions. Every query, every tool call, every data access creates a decision trace. When you persist those traces, you get a context graph—a living record of how context turned into action.

Key takeaways:

Execution path advantage: Pylar sees decisions as they happen, not after the fact. This enables capturing decision-time context that warehouses and CRMs miss.

Decision traces are first-class data: Every tool call, every query, every data access creates a trace that answers: what data was accessed, when, why, and how did it influence the decision?

Context graphs enable autonomy: When decision traces accumulate, precedent becomes searchable. Agents can learn from past decisions and apply judgment, not just rules.

The feedback loop compounds: Every automated decision adds another trace to the graph. The graph becomes more valuable over time, enabling more autonomy.

This is a new system of record: Not for objects (customers, deals, tickets), but for decisions. The context graph becomes the source of truth for "why did we do that?"

The architecture described here is what Pylar enables today. Start with capturing decision traces. Build the context graph. Enable precedent-based automation. Each stage builds on the previous one.

Most importantly: this isn't about replacing human judgment—it's about capturing it. Humans still make decisions. Pylar captures the traces, making judgment searchable and precedent applicable. That's how agents become autonomous.

This architecture pattern is what Pylar implements today. The context graph isn't a future vision—it's what emerges when you instrument the agent execution path to capture decision traces. The question isn't whether this will happen. It's whether you're building it or being replaced by it.

Product

Resources

Company

Examples