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:

1. Pull three SEV-1 incidents from PagerDuty
2. Check for an open "cancel unless fixed" escalation in Zendesk
3. Find the prior renewal thread where a VP approved a similar exception last quarter
4. Route the exception to Finance with this context
5. Record why the exception was granted

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:

• What competitor pricing data was reviewed
• What customer health signals triggered the discount
• What precedent from similar deals was considered
• What approval chain was followed

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:

• What queries the agent ran before escalating
• What customer context was reviewed
• What signals triggered the escalation decision
• What tools were called in what order

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:

• What inputs were gathered across systems
• What policies were evaluated
• What exceptions were granted
• What tools were called in what order
• What data was accessed at decision time

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:

• What: The query that was executed
• When: Timestamp of the decision
• Why: The agent's intent (from tool description and parameters)
• Context: What data was accessed, what the result was
• Sequence: What other tools were called before/after

Step 4: Context graph is updated

The trace is persisted and linked to:

• The customer entity
• The decision event (discount approval)
• Related traces (previous health checks, similar deals)
• The agent run that made the decision

What Gets Captured

1. Query Execution Traces

Every query through Pylar creates a trace:

-- What Pylar captures automatically
{
  "trace_id": "trace_abc123",
  "timestamp": "2025-12-15T10:23:45Z",
  "agent_id": "renewal_agent_v2",
  "tool_name": "get_customer_health",
  "parameters": {
    "account_name": "Acme Corp"
  },
  "query_executed": "SELECT * FROM customer_health_view WHERE account_name = 'Acme Corp'",
  "data_sources_accessed": ["salesforce", "product_analytics", "zendesk"],
  "result": {
    "health_score": 45,
    "churn_risk": "high",
    "open_escalations": 2
  },
  "decision_context": "Evaluating discount exception for renewal"
}

2. Decision Sequences

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

{
  "decision_id": "decision_xyz789",
  "agent_id": "renewal_agent_v2",
  "decision_type": "discount_approval",
  "sequence": [
    {
      "step": 1,
      "tool": "get_customer_health",
      "result": "health_score: 45, churn_risk: high"
    },
    {
      "step": 2,
      "tool": "get_recent_incidents",
      "result": "3 SEV-1 incidents in last 30 days"
    },
    {
      "step": 3,
      "tool": "find_similar_deals",
      "result": "Deal X: 20% discount approved for similar health score"
    },
    {
      "step": 4,
      "decision": "Approve 20% discount exception",
      "rationale": "High churn risk + service incidents + precedent from Deal X"
    }
  ],
  "final_decision": "approved_20_percent_discount"
}

3. Cross-System Context

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

{
  "decision_trace": {
    "customer": "Acme Corp",
    "systems_accessed": {
      "salesforce": {
        "queries": ["get_account_details", "get_contract_value"],
        "data_accessed": ["ARR: $500K", "Renewal date: 2026-01-15"]
      },
      "zendesk": {
        "queries": ["get_open_tickets", "get_escalation_history"],
        "data_accessed": ["2 open escalations", "Last escalation: 3 days ago"]
      },
      "pagerduty": {
        "queries": ["get_recent_incidents"],
        "data_accessed": ["3 SEV-1 incidents in last 30 days"]
      }
    },
    "decision_time_state": {
      "customer_health": 45,
      "churn_risk": "high",
      "service_impact": "severe"
    }
  }
}

4. Precedent Links

Pylar links decisions to similar past decisions:

{
  "current_decision": {
    "decision_id": "decision_xyz789",
    "type": "discount_approval",
    "customer": "Acme Corp",
    "discount": "20%"
  },
  "precedents": [
    {
      "precedent_id": "decision_abc456",
      "similarity_score": 0.85,
      "reason": "Similar health score (45 vs 48), similar service incidents",
      "outcome": "20% discount approved",
      "date": "2025-09-15"
    },
    {
      "precedent_id": "decision_def789",
      "similarity_score": 0.72,
      "reason": "Similar churn risk, different health score",
      "outcome": "15% discount approved",
      "date": "2025-08-20"
    }
  ]
}

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?"

SELECT 
    dt.decision_id,
    dt.decision_rationale,
    dt.systems_accessed,
    dt.precedents_considered,
    dt.approval_chain
FROM decision_traces dt
WHERE dt.customer_id = 'acme_corp'
  AND dt.decision_type = 'discount_approval'
  AND dt.decision_date = '2025-12-15';

"What precedent did we use for similar deals?"

SELECT 
    dt1.decision_id as current_decision,
    dt2.decision_id as precedent_decision,
    dt2.similarity_score,
    dt2.precedent_reason,
    dt2.outcome
FROM decision_traces dt1
JOIN precedent_links pl ON dt1.decision_id = pl.decision_id
JOIN decision_traces dt2 ON pl.precedent_id = dt2.decision_id
WHERE dt1.customer_id = 'acme_corp'
ORDER BY dt2.similarity_score DESC;

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

SELECT 
    dt.decision_id,
    dt.customer_id,
    dt.decision_rationale,
    dt.data_accessed_at_decision_time,
    dt.approval_chain
FROM decision_traces dt
WHERE dt.decision_type = 'service_impact_exception'
  AND dt.data_accessed_at_decision_time->>'sev1_incidents' > '2'
ORDER BY dt.decision_date DESC;

The Feedback Loop

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

1. Agent makes decision → Decision trace is captured
2. Trace is persisted → Added to context graph
3. Similar decisions occur → Agent queries context graph for precedent
4. Agent applies precedent → More decisions can be automated
5. Graph keeps growing → More precedent available for future decisions

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

# Agent execution
1. get_customer_health(account_name="Acme Corp")
   → Returns: health_score: 45, churn_risk: "high"

2. get_open_tickets(account_name="Acme Corp")
   → Returns: 2 open escalations, 1 critical ticket

3. get_recent_incidents(account_name="Acme Corp", days=30)
   → Returns: 3 SEV-1 incidents in last 30 days

4. check_sla_status(account_name="Acme Corp")
   → Returns: SLA at risk, response time exceeded

Step 2: Pylar Captures Decision Trace

{
  "decision_id": "escalation_decision_123",
  "timestamp": "2025-12-15T14:30:00Z",
  "agent_id": "support_agent_v2",
  "decision_type": "ticket_escalation",
  "ticket_id": "ticket_456",
  "customer": "Acme Corp",
  
  "tool_calls": [
    {
      "tool": "get_customer_health",
      "parameters": {"account_name": "Acme Corp"},
      "result": {"health_score": 45, "churn_risk": "high"},
      "timestamp": "2025-12-15T14:30:05Z"
    },
    {
      "tool": "get_open_tickets",
      "parameters": {"account_name": "Acme Corp"},
      "result": {"open_escalations": 2, "critical_tickets": 1},
      "timestamp": "2025-12-15T14:30:08Z"
    },
    {
      "tool": "get_recent_incidents",
      "parameters": {"account_name": "Acme Corp", "days": 30},
      "result": {"sev1_incidents": 3},
      "timestamp": "2025-12-15T14:30:12Z"
    },
    {
      "tool": "check_sla_status",
      "parameters": {"account_name": "Acme Corp"},
      "result": {"sla_at_risk": true, "response_time_exceeded": true},
      "timestamp": "2025-12-15T14:30:15Z"
    }
  ],
  
  "decision_context": {
    "health_score": 45,
    "churn_risk": "high",
    "open_escalations": 2,
    "sev1_incidents": 3,
    "sla_at_risk": true
  },
  
  "decision": "escalate_to_tier3",
  "rationale": "High churn risk customer with multiple escalations, recent service incidents, and SLA at risk. Precedent: Similar cases escalated to Tier 3.",
  "precedents_considered": [
    {
      "precedent_id": "escalation_decision_098",
      "similarity": 0.82,
      "reason": "Similar health score and escalation history"
    }
  ],
  
  "data_sources_accessed": ["salesforce", "zendesk", "pagerduty"],
  "decision_time_state": {
    "customer_health": 45,
    "ticket_count": 3,
    "incident_count": 3
  }
}

Step 3: Context Graph is Updated

The decision trace is linked to:

• Customer entity: Acme Corp
• Ticket entity: ticket_456
• Precedent decisions: Similar escalation decisions
• Data sources: What was accessed from which systems
• Agent run: The specific agent execution that made the decision

Step 4: Future Decisions Use Precedent

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

# Agent queries for precedent
find_similar_escalation_decisions(
    health_score_range=(40, 50),
    escalation_count_range=(2, 3),
    sev1_incidents_range=(2, 4)
)

# Returns precedent from escalation_decision_123
# Agent applies same logic: escalate to Tier 3

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:

• More precedent is available for future decisions
• Patterns emerge that weren't visible before
• Exceptions become precedents instead of re-learning the same edge case
• The system gets smarter with every decision

Schema Overview

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

Key relationships:

• agent_runs → decision_traces (decisions made in each run)
• decision_traces → tool_calls (tools used to make decision)
• tool_calls → data_access (data accessed for each tool call)
• decision_traces → precedent_links (links to similar past decisions)
• decision_traces → entities (customers, deals, tickets, etc.)

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:

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

2. 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?

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

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

5. 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.