agent-activity-log

What this skill does

# Agent activity log

A typed audit log of agent decisions, blockers, and outcomes — opt-in for users who are explicitly building an agent-driven workflow. The selling point: humans (and the next agent session) can read back what the agent did and why, without trusting a context-window summary that may be gone tomorrow. Pairs naturally with Airtable's role as a persistent agent substrate.

This skill owns the schema and disclosure language. Workflow skills (product-ops, sales-ops, marketing-ops, etc.) compose this skill rather than re-implementing the pattern; they trigger it when the user's intent surfaces an agent-driven workflow and pass through to this skill for the scaffolding + ongoing use.

## When this fires

Trigger phrases — workflow skills should offer this to the user when any of these surface:

-   _"track what the agent is doing"_, _"agent activity log,"_ _"audit log of agent decisions"_
-   _"long-running workflow,"_ _"agent memory,"_ _"persistent state for the agent"_
-   _"keep a record of what changed and why"_
-   Setup-mode invocations describing an agent-driven motion: _"I want the agent to triage feedback every morning,"_ _"the agent should propose changes for me to approve,"_ _"set up a self-running workflow"_

Surface proactively when the user's language signals they're building something the agent will run repeatedly or autonomously — not for one-shot interactions.

## Disclosure (opt-in, not surveillance)

Front-load the offer. The user agrees up front or declines; either is fine.

> _"I can also set up a log of my own activity in a table called `Agent activity log` so you can audit what I've done and why. It tracks every record I create or modify with the reasoning. It's opt-in — if you'd rather not have it, we'll skip it. Want me to include it?"_

Frame as **auditability for the user's benefit** — they can see what the agent decided, what got changed, and where the agent got stuck. Not as monitoring the agent for its own sake.

## Schema

A single `Agent activity log` table. Keep it out of stakeholder-facing Interfaces — this is internal audit data for the agent's operator, not content the broader team should browse in the app.

### Core fields

-   **`Summary`** (singleLineText, primary) — one-line what-happened. This is the **primary field**.
-   **`Timestamp`** (createdTime) — when the event happened.
-   **`Action`** or **`Event type`** (singleSelect: `Read`, `Create`, `Update`, `Delete`, `Decision`, `Blocker`, `Question`, `Completion`, `Error`) — adapt the choices to the workflow's grain.
-   **`Reasoning`** or **`Detail`** (multilineText) — what the agent intended and why, including inputs considered and alternatives rejected
-   **`Outcome`** (singleSelect: `Completed`, `Partial`, `Failed`, `Blocked`)
-   **`Status`** (singleSelect: `Open`, `Acknowledged`, `Resolved`, `Stale`) — for blockers and questions that need human follow-up
-   **`Session ID`** (singleLineText) — tie events from one agent invocation together

### Linking to the records the agent touched

**Airtable's `multipleRecordLinks` field is bound to a single target table at field-creation time** — there is no polymorphic linked-record field that spans multiple tables. Two viable patterns:

1. **Per-target linked-record fields (recommended)** — one `multipleRecordLinks` field per table the agent might touch. For a product-ops base: `Linked Roadmap item`, `Linked Customer feedback`, `Linked Release`, `Linked OKR`. For a sales-ops base: `Linked Account`, `Linked Contact`, `Linked Opportunity`, `Linked Activity`. The agent populates whichever field matches the touched record's table; the others stay empty. **Gives reverse-link navigation** — opening a touched record shows all `Agent activity log` entries that touched it, automatically. Slightly more schema overhead per added table the agent touches.
2. **URL-only fallback** — a single `Target record URL` (URL field) holding the deep-link to the touched record. No reverse-link navigation, no rollups across the log, but simpler schema. Reasonable when the agent touches many tables and per-table linked fields would get unwieldy, or for early-stage setups where browser-driven inspection is fine.

Most builds use **pattern 1 for the 3-5 tables the agent touches most often + pattern 2 as fallback for ad-hoc touches** — add a `Target record URL` field alongside the per-table linked-record fields and populate it whenever the touched record's table isn't one of the wired-up linked fields.

Add a `Target table` (singleSelect of the workflow's tables) so a viewer can quickly see which kind of record an entry touched, even before clicking through.

### Schema variants per workflow domain

The shape is the same across workflow skills; the per-target linked-record fields change to match the parent base's tables. The workflow skill that's invoking `agent-activity-log` knows its own table inventory and should pass them through.

## Use guidance

Throughout any agent-driven session, write events to the log as decisions are made or blockers surface. Pattern:

1. **At session start**: write an event with `Action = Completion`, `Outcome = Completed`, and `Summary` describing what the session is starting on. The `Session ID` for this entry becomes the tie-thread for the rest of the session's writes.
2. **On each meaningful decision**: write a `Decision` event with the full reasoning in `Reasoning`. Include alternatives considered and why they were rejected.
3. **On blockers**: write a `Blocker` event with `Status = Open`, link to the affected records via the per-table linked-record fields.
4. **On questions for the human**: write a `Question` event with `Status = Open`, link to the affected records. The human can answer by updating the record (e.g., adding a comment or moving status to `Acknowledged`).
5. **On errors**: write an `Error` event with `Outcome = Failed` and the error context in `Reasoning`.
6. **At session end**: write a `Completion` event summarizing the session's outputs and any unresolved items.

Don't over-write — log meaningful decisions and changes, not every tool call. Reads in particular usually don't need to be logged unless the workflow's audit value depends on it.

## Composition into workflow skills

The workflow skill (product-ops, sales-ops, marketing-ops, etc.) should:

1. **Surface this pattern to the user** when the trigger phrases above appear, framing it as opt-in.
2. **Compose `agent-activity-log`** — don't re-implement the schema inline; point at this skill the same way workflow skills point at `show-airtable-link` for the URL-handoff pattern.
3. **Pass through workflow-specific context** — the tables the agent will be touching, so the per-target linked-record fields can be scaffolded correctly for that workflow.
4. **Hand off at session end** via `show-airtable-link` — link to the `Agent activity log` table or to a "Recent agent activity" Interface view so the user can inspect.

Suggested workflow-skill body language:

> _"When the user wants agent-activity tracking (`'audit log of agent decisions,' 'long-running workflow,' 'agent memory,'` etc.), compose the `agent-activity-log` skill. Frame as opt-in — disclose first, scaffold after the user agrees. Pass the workflow's record-touching tables through so the per-target linked-record fields get scaffolded for the right tables."_

## Composition with `show-airtable-link`

At session end (or when surfacing what the agent did), hand off to the user with a `show-airtable-link` to the `Agent activity log` table — or to a dedicated Interface view filtered to the current `Session ID` so the user sees only this session's activity. Both are valid; pick based on the user's stated preference for browsing vs. session-by-session review.

## Anti-patterns

-   **Don't auto-create `Agent activity log` without disclosure.** This pattern earns trust when offered; it erodes trust when imposed. Always disclose first.
-   **Don't claim "polymorphic" linked-rec