Persistent agent memory

Keva Brain

Stateless AI processes support requests in isolation, forgetting what happened before. Keva Brain provides a guarded tenant-scoped memory path.

Tenant-scoped typed memory can add eligible support context to an initial agent run. Configured, deployed behavioral improvement remains to be proven.

Growth+
Plan Availability
Tenant
Scoped Memory
4
Typed Categories
Initial
Agent Run Recall
The problem with stateless AI

Traditional AI support agents can treat a repeat request like a blank slate. A customer writes in about the same billing issue for the third time, and the earlier context is unavailable.

Durable records are useful only when the right evidence is admitted safely. Client Brain provides one typed, tenant-scoped context path for eligible support memory.

Keva can make selected tenant-scoped memory and evidence available as agent context.

How the data flows

Typed recall is available to the initial agent run

Recall is guarded and optional. Continuation can reload fresh tenant-scoped live Client Brain context.

1

Ticket arrives

A customer submits a support request through email, widget, or API.

2

Initial recall

The initial agent run can load valid typed tenant memory. Continuation can reload fresh tenant-scoped live Client Brain context.

3

Agent receives context

Admitted memory is prompt context, not proof that it changed the response or outcome.

4

Eligible learning attempt

A newly terminal ticket can request extraction; runtime and provider gates can skip it.

Data pipeline
Ticket arrives
Load Brain context
Agent runs with memory
Action executes
Attempt learning

Coral steps show the Client Brain boundary. Learning is requested only for eligible terminal tickets and can skip; prompt admission is limited to valid typed memory.

What Client Brain can store

Four typed memory categories

Business, voice, issue, and process values must pass typed validation before prompt admission.

Layer 1: Business Memory

Per tenantRetention policy pending

“Refund requests require a valid receipt.”

A non-empty business fact can be extracted from eligible terminal-ticket evidence and stored with source-ticket provenance.

Illustrative typed value
Business fact:
Refund requests require a valid receipt.

Source: eligible terminal ticket
Why this matters

A valid business fact can be included in a later initial agent run. Inclusion is not proof that it changed a response.

Layer 2: Voice Memory

Per tenantRetention policy pending

“Use a formal, concise support style.”

Supported voice fields can be extracted when eligible evidence includes a human-edited AI draft and qualifying outbound response.

Illustrative typed value
Voice:
Level: formal
Prefer phrases: "Thank you"
Avoid phrases: "No problem"
Why this matters

Voice memory can provide style context to an initial run. Its effect on the generated response requires product verification.

Layer 3: Issue Memory

Per tenantRetention policy pending

“Shipping delays recur after a particular fulfilment state.”

An issue memory requires a pattern, a best-resolution description, and a finite frequency value.

Illustrative typed value
Issue: fulfilment delay after dispatch
Best resolution: verify carrier scan, then update customer
Frequency: 3
Why this matters

Issue memory can expose a prior pattern and resolution as context; it does not guarantee that the model will reuse it.

Layer 4: Process Memory

Per tenantRetention policy pending

“Verify identity before issuing a refund.”

A process memory stores a trigger and an action extracted from eligible approval and resolution evidence.

Illustrative typed value
Trigger: customer requests a refund
Action: verify identity before issuing the refund
Why this matters

Process memory can remind an initial run of a stored trigger/action pair. Following it remains a model behavior to verify.

Separate Execution Capability

Browser actions are not Brain training

Browser automation is a separate execution capability. Client Brain does not automatically learn reusable browser playbooks, cache authentication flows, or turn navigation sessions into typed support memory.

Explicit Playbooks

Defined and supervised separately

A browser workflow can be defined and supervised as a separate playbook. Successful execution does not automatically create a playbook or prove that later runs will be faster.

Playbook definition, credential handling, execution evidence, and verification have their own contracts. This page does not claim cached sessions, learned selectors, or automatic playbook creation.

Execution Evidence

Kept separate from Client Brain

Browser actions can produce execution records and outcomes. Those records must not be described as automatic Client Brain learning, reusable authentication memory, or verified navigation improvement.

The exact evidence fields, persistence, retention, and replay behavior must be verified against the relevant executor. No login method, navigation path, selector, or recovery-memory guarantee is made here.

Current boundary: Browser automation and Client Brain are separate. Reuse, speed, and reliability improvements require configured, deployed behavioral verification.

Before and after Keva Brain

Context available, behavior still to verify

These are context boundaries, not guarantees that a model used the memory or improved an outcome.

Without Brain

No durable tenant memory is available

With Brain

A valid typed memory can be included in an initial run

Without Brain

Prior support evidence is unavailable

With Brain

Stored evidence can be presented as additional context

Without Brain

Recent failure context is absent

With Brain

Available safety evidence can accompany the request

Without Brain

Repeat-customer context is absent

With Brain

Structured customer context can be made available

Without Brain

Platform context must be rediscovered

With Brain

Previously recorded connector context can be supplied

Under the hood

Guarded, typed, and tenant-scoped

For the technically curious. Keva Brain is designed to be invisible.

Skip-capable learning

Learning can skip when ticket eligibility, runtime, or provider gates are not met. A skipped attempt must not be counted as a learned outcome.

Typed initial context

The initial run fetches candidates in two bounded tiers inside the finite 0.5–1 range. The fallback tier fetches up to 200 candidates ordered by confidence, newest row, then ID. When the ticket subject or latest customer message has words of at least three characters, a second tier also fetches up to 200 candidates whose memory key or value contains any of those words case-insensitively, so a matching memory is not lost to the fallback window when a business has thousands of stored rows. It keeps voice memories first. For each non-voice memory, it counts shared normalized Unicode words or numbers of at least three characters between the ticket subject or latest customer message and the memory key or value; positive overlap ranks first, then higher confidence, then the original fetched order. With no overlap, the confidence-ordered fetched set is the deterministic fallback. It then admits up to 30 business / 1 renderable voice / 5 issue / 5 process rows; valid business facts over the cap are counted, and the prompt reports how many were omitted. Continuation can reload fresh tenant-scoped live context.

Source provenance

Learning re-reads the exact tenant ticket and stores source-ticket references. Multiple memories from one attempt are replay-safe individually, not one all-or-nothing transaction.

Read-only dashboard

The authenticated dashboard lists bounded offset pages and separates shared-guard-valid typed rows from all stored rows. Prompt selection remains narrower. Editing, deletion, and reset controls are not currently available.

Retention custody pending

The registered pruning job is suspended until tenant retention and deletion custody is implemented. No automatic decay, expiry, or deletion guarantee applies.

Tenant-scoped

Client Brain reads and learning custody use tenant identity. Cross-tenant contribution and bootstrap remain suspended pending stronger privacy and provenance controls.

Common questions

Frequently asked

When does Keva Brain run?

Learning is attempted only for eligible solved, closed, or resolved tickets and can skip when runtime or provider gates are not met. Valid typed memory can be loaded for an initial agent run; continuation can reload fresh tenant-scoped live context.

How much does Brain add to my AI costs?

Brain is included in eligible plans with no separate Brain fee. Actual provider usage depends on successful extraction attempts; no fixed per-ticket cost or latency claim is made.

Can I see what the Brain knows?

Yes. The authenticated Client Brain dashboard separates typed-value-valid rows from all stored rows, supports type filters, and can load subsequent bounded pages. Typed-row totals are not a claim that every row enters a prompt. The dashboard is currently read-only: edit, delete, and reset controls are not available.

What happens if I disconnect a platform?

Connector knowledge is deleted automatically (CASCADE on connector deletion). Action journal entries are retained for historical reference since they're linked to tickets and customers, not the connector itself.

Does Brain share data between tenants/workspaces?

Per-tenant Brain data stays tenant-scoped. Cross-tenant global contribution and bootstrap are suspended while deterministic privacy, provenance, withdrawal, and evidence controls are completed.

Does Brain automatically forget old memories?

No active decay or pruning guarantee applies. The registered pruning job is suspended until tenant retention and deletion custody is implemented.

An AI agent that actually remembers.

Eligible terminal tickets can contribute tenant-scoped memory. Behavioral improvement requires product verification.

Custom setup tailored to your stack. We adapt to you.

Book a Demo