Every call your agent makes states its purpose

Before Plexara runs a query or calls an API, the assistant states in one sentence what the call is for. The line is the question behind the query, not a restatement of it. SELECT * FROM finance.regional_performance LIMIT 500 is the statement. "Finding which datasets carry customer email so they can be masked." is the purpose.

That distinction is the point of the line. A statement says what ran. A purpose says why anyone would have run it, in words a person who never saw the SQL can still read. It is also the only line about the call a person wrote (through the agent they are talking to), which is why it leads every row later: in My Calls, in a session timeline, in the provenance of a saved report.

On the ACME demo deployment, the catalog includes "Checking whether Q3 revenue fell in the western region for the board deck." The statement under it is a SELECT against inventory.return_rates. A later reader does not have to infer the board deck from the table name. A purpose that restates the SQL ("query the return rates table") would not have been useful. The useful line names the decision the call was meant to inform.

Activity has My Sessions beside the overview. A session is every tool call sharing one session id, readable long after it ended, as far back as audit history reaches.

Each row carries the session's kind (Agent, Portal run, Script run, or Transport), the persona it ran as, how many calls it made, how many of them failed, and what it left behind. Facets narrow the list: a time window of 24 hours, 7 days, 30 days, or all time (the list opens on 7 days), session kind, sessions with at least one failed call, and sessions that saved at least one asset.

The list is always your own. There is no user column. A session id belonging to someone else is answered as not found, the same answer an id that was never used gets. Administrators read every session from Admin.

Open a row and the detail shows the session at a glance: calls, failures, wall-clock duration, and the assets and insights it produced. Below that is the timeline: its calls in the order they were made, each with the purpose the agent stated, the connection it went to, whether it succeeded, and how long it took. The page is addressable, so you can bookmark it. A colleague who is not an administrator will get a not-found, because a session opens only for the person who ran it.

On the ACME demo, one Agent session (dps_9f2c1a4bd1c0f9e8c5a4b3e2) shows 61 calls, one failure, one saved asset (Q4 Revenue Dashboard), and fourteen insights, some applied, some still pending, one rejected. The My Sessions list around it shows the other kinds in the same window: a Portal run of seven calls, a second Agent session of 67 calls with four failures, and a Transport session of nine. Kind, persona, call count, failures, and what was produced sit on the row before anyone opens it.

My Calls is the catalog of every query against a query engine and every invocation through the API gateway, kept with the reason stated for it and what came of the result. Each row leads with the purpose and carries the statement under it. Facets narrow by kind (SQL or API), connection, outcome, and free text over the purpose and the statement. Awaiting review keeps the records that answered something and have not been published or declined, most re-run first.

The Outcome column is what the catalog exists for, and it is derived on every read rather than stored. Four values cover the life of a call. satisfied means something was built from it and named it: an asset or a capture whose sources cite it, or an export citing the statement it streamed. failed means the call returned an error. superseded means a later read in the same session addressed the same resource, and nothing was built from this one. ran means the call succeeded and nothing has come of it yet.

Deriving the outcome rather than storing it means it cannot be stale with respect to the asset that gives it meaning. Save an asset citing a query and the query reads satisfied on the next read, with nothing to backfill. Naming, not proximity, is the rule: an asset saved without naming its sources still records every call the session made in its provenance, and those calls still read as ran. What makes a call satisfied is an artifact naming it.

A query that answered a question can be published as a saved query in the catalog, associated with every dataset it reads. An API call can be published as a saved example on its endpoint, shown to whoever reads that endpoint's schema next. A record you decide is not worth publishing can be declined with a note, which stops it being offered.

On the ACME catalog, "Establishing the current definition of an active account for the exec summary" reads satisfied against acme-warehouse. "Finding which datasets carry customer email so they can be masked" also reads satisfied, and two later sessions found that record and ran what it holds; that reuse count is the one signal on a record that a stranger, not its author, found it worth running. "Checking whether Q3 revenue fell in the western region for the board deck" still reads ran: it succeeded, and nothing has been built from it yet.

Every save records the queries and API calls the asset was built from. Each captured call names its kind (a SQL statement, an API request, or another data call), the connection it ran against, the purpose the agent stated, how long it took, and whether it failed. A failed call is shown, not hidden, because it is part of how the answer was reached.

The asset viewer groups those calls by capture, one per time the asset was written, so a revised asset shows what fed each of its versions. The newest capture is shown expanded; earlier ones sit behind a disclosure. Opening a call shows the full statement or request, its outcome, and a copyable reference. The panel also links to the session the work belongs to, which holds every call that session made, before and after the write.

The assistant can name the exact calls it used. When it does, the capture is marked Cited, and those named calls are what make the catalog rows read as satisfied. A capture the platform took from the session window around the save is the record of what the session did; being in that window is not a claim that a given call produced the asset. Saving a second asset in the same session records the calls made since the first save, not the whole session again.

On a Weekly Inventory Report in the demo, the provenance of version 1 still shows a failed query: "Summing stock per warehouse for the weekly report," 95 milliseconds, TABLE_NOT_FOUND on inventory.level. The next call, same purpose, succeeded in 1.1 seconds. Hiding the miss would make the record of the work untrue. The person who opens the report next week can see how the answer was reached, including the wrong table name that did not survive.

The assistant finds its own past work the way a person does: by what it was for, not by an id it kept. Ask what it ran last Tuesday and search matches the caller's own sessions against the purposes their calls stated and the names of the assets they saved. A hit carries a session reference. Fetch opens one: its summary, the assets and insights it produced (each as a reference to follow), and its call timeline in order. Every call on that timeline carries the purpose stated for it, and a call the catalog recorded also carries its kind, its outcome, and the reference that reads the record in full.

The scope is the same as My Sessions. An agent recalls the sessions of the person it is acting for and no one else's. Another person's session id is answered as not found.

The catalog of calls exists so the next person can find the query that already answered a question. Automated work was crowding it out: a pipeline fetching through the same tools people use writes a record per fetch that nobody will ever re-run.

Calls made by a managed script's run, and by the accounts that drive ingestion, are recorded in the audit trail as before and kept out of that catalog. Records written before the distinction was drawn are cleared, with anything that was built on, promoted, declined, or re-run kept whoever produced it. The catalog stays a list of calls a person might re-run. The audit page still names the principal behind each option, so a script run reads as that script rather than as its owner.

This week: open Activity, read one of your sessions all the way through the timeline, and publish one query that worked so the next person starts from something that already answered the question.