0 Why Temporal?
Context-setting (if audience is new to Temporal):
"Before we dive into the demo, let me quickly explain why we're using Temporal for agent orchestration."
Key insight: "The big advantage is that developers just build to the happy path. You write your workflow as if nothing will fail, and Temporal handles retries, timeouts, and crash recovery automatically."
"Traditional systems require defensive coding everywhere — retry logic, state machines, idempotency checks. With Temporal, you write workflow.Execute(activity) and trust the platform."
Durability guarantee: "Temporal gives you guarantees for getting into a known state. Every workflow reaches a definitive end — completed, failed, or timed out. No more 'is it still running?' uncertainty."
"If a process crashes, a server restarts, or there's a network partition — workflows resume exactly where they left off. State is durably persisted at every step."
Transition: "So Temporal is great at orchestration and durability. But it wasn't designed to be a long-term audit database. That's where XTDB comes in. Let me show you the problem..."
1 Introduction & Problem
Opening (while stats are visible):
"Today I want to show you something we've been working on around decision observability for AI agent orchestration."
Action: Point to the three stat boxes at the top
"What you're looking at is a customer service AI agent orchestrated by Temporal. It analyzes tickets, looks up customer profiles, checks churn risk signals, and routes to the appropriate queue."
"But here's the problem: the ML model predictions have propagation lag. By the time a customer is flagged as high-risk in one system, they may have already been routed to the wrong queue."
"This creates a compliance nightmare. When a regulator asks 'what did your AI know when it made that decision?' — you need to answer that with precision."
2 Live Demo Walkthrough
Audit Tab (default view):
Action: Ensure "Audit: Misrouted Customers" tab is active. Point to the SQL query box.
"This is a bitemporal query. Notice the FOR VALID_TIME AS OF clause — this asks XTDB: what churn predictions were valid at the exact moment this routing decision was made?"
Action: Point to the table rows, especially the "Lag" column
"Look at this customer — they were flagged as 95% churn risk 45 minutes before the routing decision. The information existed. Our agent just didn't have access to it in time."
"That's 5 customers who should have gone to the priority queue. These aren't hypotheticals — this is what was known at decision time."
Action: Click the "Counterfactual Analysis" tab
Counterfactual Tab:
"Now let's see what actually happened to these customers. Click 'Counterfactual Analysis'."
Action: Point to the churned/retained stats and the $21K lost LTV
"Every single high-risk customer churned. That's $21,000 in lost lifetime value from customers we could have prioritized."
"This is the counterfactual: if our agent had the real-time data, we could have intervened. This query joins churn predictions with actual outcomes — something that requires keeping both datasets with their temporal context."
Action: Click the "Event Timeline" tab
Timeline Tab:
"This is the unified timeline. Three different data sources — Temporal workflow events, ML model predictions, and customer outcomes — all queryable together."
Action: Scroll the timeline slowly. Point out the different colored dots.
"Blue dots are workflow events from Temporal. Yellow are churn predictions. Red are actual churn outcomes. All ordered by when they really happened, not when we recorded them."
"This is what regulators want to see. A complete audit trail across all your systems."
Action: Click the "Workflow Events" tab
Workflow Events Tab:
"Now here's something new — we've added full payload capture. Select any workflow and you can see every event with its complete data."
Action: Select a workflow from the dropdown. Click on an ActivityTaskScheduled or ActivityTaskCompleted event to expand it.
"Look at this activity — you can see the full activity_input with the Ticket details, customer Profile, Sentiment analysis, Churn risk, and Routing decision. This is the exact data the AI agent used to make its decision."
"For compliance, this is critical: 'what inputs did the agent receive?' and 'what was the output?' — now you have answers with the precise data, not just event types."
3 Activity Decision Context
"Now let me show you something that goes beyond CDC. Click the 'Activity Context' tab."
Action: Click the "Activity Context" tab
"We have two ways to capture decision data:"
- CDC via Kafka Connect — streams Temporal events automatically. Captures what the workflow did.
- Direct Activity Writes — activities call
xtdb.Save(ctx) explicitly. Captures what external systems believed at the exact moment a decision was made.
Action: Point to the two tables: Churn Signals and Routing Decisions
"On the left, you see activity_churn_signals — these are the churn scores the activity received from the ML model at decision time. On the right, activity_routing_decisions — the full context that informed each routing decision: sentiment, urgency, customer tier, LTV."
Key insight: CDC captures workflow structure. Direct writes capture the external state — ML predictions, CRM data, anything the activity consulted. Together, they answer: "what did the agent do?" and "what did it know?"
"For compliance, this is critical. You can now prove not just the decision, but the complete context that informed it."
4 Before/After Corrections
"Now let me show you something that really demonstrates why bitemporality matters."
Action: Click the "Before/After Corrections" tab
"We've simulated a real-world scenario: an ML model correction arrives after decisions have already been made. Three customers — CUST-002, CUST-006, and CUST-010 — were originally scored as low or medium risk. The corrected model says they were actually high risk."
"The key SQL here is SETTING DEFAULT SYSTEM_TIME TO AS OF. This tells XTDB: show me the database as it was before the corrections arrived. Not a backup. Not a snapshot. The actual live database, time-traveled."
Action: Point to the "Before Corrections" panel on the left
"On the left: what the audit query returned before corrections. These are the customers we already knew about."
Action: Point to the "After Corrections" panel on the right, then the "Newly Detected" section
"On the right: the same query, same data, but now. Three new customers appear. They were invisible to the audit before the model correction."
"Think about what this means for compliance: without bitemporality, the corrections would overwrite the original scores. You'd never know these customers were missed. With XTDB, both the before and after states are preserved — permanently."
Takeaway: This is the difference between "we fixed our model" and "we can prove exactly what changed and when." Regulators care about both.
5 Temporal's Audit Limitations
"Now, you might ask — can't Temporal do this natively? Let me share what we're hearing from the community."
Pain Point 1: Retention Limits
"I run a financial application, and I rely on querying the completed workflows. As Temporal deletes the completed workflows, it's a big problem for my application."
— Temporal Community Forum
"The 90-day retention window has been a real issue for us."
— Betashares (financial services)
The problem: Temporal Cloud offers 30-90 days retention. HIPAA requires 6 years. SOX requires 7 years. There's a massive gap.
Pain Point 2: Querying is Hard
"I have a workflow tracking the state of a payment... What's the best way to find out how many payments are currently pending?"
— Temporal Community Forum
"We tried querying Cassandra directly, but it seems it serialized into a thrift binary object."
— User attempting direct DB access
The problem: The Visibility API has limits. Direct DB queries hit serialized blobs. Users are stuck.
Pain Point 3: Audit Gaps
"Audit Logs do NOT capture data plane events, like Workflow Start, Workflow Terminate, Schedule Create, etc."
— Temporal Documentation
The problem: Temporal's audit logs cover the control plane (who logged in), not the data plane (what decisions were made). For compliance, you need both.
Pain Point 4: Export Pipeline Complexity
"Convert protos to another format to perform analytics... upload into your data store: Athena, Redshift, Snowflake or Databricks."
— Temporal Documentation
"Export has 'at least once' guarantee. Please dedupe based on runID. Schema of Parquet files may change."
— Temporal Export Caveats
The problem: The official answer is a complex ETL pipeline with deduplication, schema evolution, and data warehouse integration. That's months of engineering.
6 Why XTDB Solves This
"XTDB is a bitemporal database. That means every record tracks two timelines:"
- Valid Time (
_valid_from): When was this fact true in the real world?
- System Time (
_system_from): When did we record it?
Benefit 1: Point-in-time queries are native. FOR VALID_TIME AS OF timestamp is first-class SQL syntax, not a workaround.
Benefit 2: Unlimited retention. Keep data for 7+ years without complex archival pipelines.
Benefit 3: Join across sources. Temporal events, ML predictions, CRM data — all in one query.
Benefit 4: PostgreSQL wire protocol. Your existing tools (psql, Metabase, dbt) just work.
"What we've built here is a CDC connector that streams Temporal workflow events into XTDB in real-time. No batch ETL. No schema conversion. Just SQL."
Action: Point back to the Audit tab
"That query you saw? It's running against live data. The workflows completed seconds ago. The churn predictions came from a different system. And we're joining them with precise temporal semantics."
7 Closing
Summary:
"If you're using Temporal for AI agent orchestration — or any workflow where decisions matter — you're going to face these questions:"
- What did the agent know when it made that decision?
- What should it have known?
- Can we prove this to a regulator in 3 years?
"Temporal is great at orchestration. But it wasn't designed to be an audit database. XTDB fills that gap."
Call to Action:
"We're looking for design partners who are building AI agents with Temporal and need compliance-grade observability. If that's you, let's talk about what your audit requirements look like."
Action: Open for Q&A. Common questions below.
Anticipated Questions:
- "What's the latency?" — Sub-second. CDC connector polls every 10s by default, configurable.
- "How much data can it handle?" — XTDB scales horizontally. We've tested millions of events.
- "Does it work with Temporal Cloud?" — Yes, uses the standard gRPC API.
- "What about other workflow engines?" — The pattern applies. We're starting with Temporal because that's where the demand is.
