Edge
Every agent interaction produces data your systems never captured: not just what was said, but what was looked up, what was decided, and what happened at every step.
Book a demoCaptured during execution
Each workflow persists the variables, outcomes and extracted fields it was configured to keep, written as the run completes rather than reconstructed later, so there's no post-processing step and no manual review to fall behind on.
Custom variables and extraction rules
Standard classifications like outcome, intent and sentiment come out of the box, and beyond them you define what matters: a quoted price, a document reference, a compliance acknowledgment.
Entity mapping
Every data point is mapped to the entity it belongs to, like a contact, an account, a vendor, and entities are connected to one another, so what accumulates is a structured picture of your operation rather than a pile of unattributed records.
An active data layer
Agents query it during a live session to retrieve a value from a prior interaction or check whether a condition was met before. And a write can trigger the next workflow.
Is it the same fault as last time?
support_calls where contract_id = 40219
Yes, E12 again, low pressure. I can book an engineer for Thursday.
Retention, isolation and portability
Retention windows are configurable per deployment and enforced automatically, and every deployment's data is fully isolated and never used to train shared models. The whole layer is queryable from your BI tools over the REST API.
GET /v1/tables/support_calls/rows
{ "contract_id": 40219, "error_code": "E12" }
FAQs
A transcript is what was said; agentic data is what happened. The same session produces fields (the rate quoted, the tool called, the reason a carrier declined, the outcome written) structured and queryable rather than buried in prose. Transcripts are part of the record, but they're the least usable part of it.
You do, per workflow. Standard classifications like outcome, intent and sentiment are available by default, and beyond those each workflow defines its own extraction rules for the fields that matter to it. An inbound support workflow might capture resolution status and escalation reason; an outbound follow-up captures objection type and next action. Both land in the same structured layer.
Yes, that's the point of a single layer rather than per-workflow storage. A table written by a check-call workflow can be read by a rate negotiation workflow, a reschedule workflow, or a custom app, without any of them needing to know how it got there. The record compounds because everything writes to and reads from the same place.
Yes. Define the new variable and its extraction rule, and it starts being captured on subsequent runs. Where you need history on it too, a backfill can replay completed runs into the same table, so a field added in month six doesn't leave you with five months of blanks.
A warehouse gives you unstructured records after the fact, which then need extracting, structuring and entity-resolving before anyone can query them, and by then the conversation is over. Here the structuring happens during execution, the data is mapped to entities as it lands, and an agent can read it mid-conversation. The warehouse still gets everything, over the REST API, once it's already useful.
