Agent-created tables

When a workflow needs to persist intermediate state, it can create its own managed table — with extra governance to keep the blame chain clear.

Workflows sometimes need to persist intermediate state — a deduplicated entity list, a scoring matrix, a sample of a long-running run. Scrydon supports this through agent-created managed tables, with extra governance to keep the actor chain auditable.

The model

An agent-created table behaves exactly like a user-created table in every respect (lifecycle, classifications, masks, row filters) — with three extra invariants:

Invariant	Why
Table name must start with `agent_`	Visible in lists, search, and the audit log — you can always tell which tables a workflow created.
Default classification is `confidential`	Workflows aren't given a public default. An admin can lower it explicitly.
Every row carries actor metadata	`actor_type`, `deployer_user_id`, `workflow_id`, `workflow_run_id` — the blame chain back to a user.

User-created tables cannot start with agent_. This split makes "did a human or an agent put this here?" answerable with a glance.

When a workflow can create a table

The workflow must:

Be triggered by a user who has the managed-table:create grant in the target workspace.
Have an explicit create-table step in its definition — the create isn't implicit.
Pass through the same authorisation check as a user-driven create.

The execution grant the workflow holds is what permits the create; the workflow can't escalate beyond what the triggering user had.

Actor identity columns

Every row inserted by a workflow carries five extra columns:

Column	Value
`_actor_type`	Always `"agent"` for these tables
`_actor_run_id`	The run ID of the workflow that wrote the row
`_actor_workflow_id`	The workflow definition ID
`_actor_deployer_user_id`	The user who deployed / owns the workflow
`_actor_inserted_at`	UTC timestamp of the write

These columns are reserved — you can't define your own columns with the leading underscore prefix. They're populated automatically; the workflow doesn't see or set them.

Why the extra columns

A managed table is a long-lived artefact. A workflow that wrote a row last quarter may not exist any more, and the user who triggered the run may have left the org. The actor columns give compliance auditors and incident responders a permanent trail back to the originating context — which workflow definition, which run, which deployer.

Removing or modifying actor columns requires explicit org-owner action.

You can grant a workflow the ability to create tables, but you can't grant a workflow the ability to bypass the agent-creation invariants. A workflow that tries to write to a table with a name that doesn't start with agent_, or that tries to set _actor_type to "user", is rejected by the data plane.

Reading from agent-created tables

Reads follow the same governance as any other managed table. The _actor_* columns are always available to workspace admins; whether workspace members see them depends on the table's mask strategies.

Managed tables — the base lifecycle.
Classification & masking — how the confidential default plays out.
Security → Authorization — the execution grant model that gates these writes.
Audit logging — every agent create / write is recorded.