Change Log

Overview

The Change Log is a complete audit trail of every configuration change made to your agent. Unlike Runs — which tracks execution — the Change Log tracks mutations: what was changed, when, by whom, with the exact before and after values, and a one-click way to undo it.

Every time your agent updates its own settings, edits one of its skills, or a team member changes configuration through the UI, a change entry is recorded. This gives you a transparent, reviewable history of how your agent has evolved over time — and a safe way to roll back when something doesn't pan out.

Where to Find It

The Change Log lives inside the History tab as a sub-tab next to Runs. Both views share a toolbar row so you can switch between execution history and configuration history without losing context.

• Runs — What the agent did
• Changes — What the agent became

What Gets Tracked

The Change Log captures mutations across six configuration surfaces. Both agent-initiated changes (chat, settings_manager, manage_skills, skill sync) and user-initiated changes (saves from any UI tab) are captured uniformly — same schema, same diff view, same revert flow.

Only fields that actually changed are recorded — no-op saves don't clutter the log.

Anatomy of a Change Entry

Each entry is rendered as a card on a vertical timeline (commit-rail style), containing:

• Operation icon — Color-coded by entity type (settings, mail, voice, scheduled job, skill, skill file)
• Entity name — What was changed (e.g., "Agent Settings", "Scheduled Job: Daily Digest", "Skill: Lead Researcher")
• Operation badge — Created, Updated, or Deleted
• Actor badge — Who made the change (agent, user, or system)
• Inline preview — For single-field updates, shows the before → after values directly on the card
• Relative timestamp — e.g., "3 minutes ago", with the exact time on hover
• Revert button — On revertable entries, a one-click revert is exposed in the detail drawer

Click any entry to open the full detail drawer.

Operations

Actors & Sources

Every change is attributed to one of three actor types, so you can always tell who made a change:

Agent-driven entries link to the chat session and run where the change originated, so you can trace a setting change back to the exact conversation that caused it.

Source

Beyond the actor, every entry also records a source — the specific code path that wrote the change. The detail drawer surfaces this so you can tell, for example, whether the agent changed a setting through chat (settings_manager) or as part of skill maintenance (manage_skills).

Filtering

The toolbar in the top-right of the Changes sub-tab lets you narrow the timeline by category:

• All changes (default)
• Agent settings — Title, persona, sandbox, working hours, chat, actions, queue
• Mail & Voice — Channel-specific configuration and processing instructions
• Scheduled jobs — Create, update, delete on time-based triggers
• Skills — Skill and skill-file changes

Filters work alongside the grouping — filtered entries still cluster under their date headers.

The Change Detail Drawer

Clicking any entry opens a side drawer showing the full field-by-field diff for that change:

• Every modified field listed with its before and after values
• Multi-line strings (like email_processing_instructions or a scheduled job prompt) rendered in full — no truncation
• JSON/object fields pretty-printed for readability
• Actor details (name, email, session, run) plus the source badge, with links back to the originating chat and run
• A Revert button on revertable entries (see next section)

This is especially useful for verifying agent-made changes to long-form settings like processing instructions — you can see the exact text the agent wrote, character-for-character.

Reverting a Change

Most entries can be reverted with a single click from the detail drawer. The system handles the messy parts for you — drift detection, cascading restores for skill files, and pushing reverted content back to your running sandbox.

What's Revertable

Rollback rows themselves (source: rollback) are not revertable — to undo a revert, just revert the rollback row's predecessor instead, or make the change manually.

Drift Detection

If the entity has changed since the entry was written (e.g., someone edited the field again, or the agent overwrote it), reverting could clobber newer work. The API detects this and asks for confirmation:

Confirming forces the revert; the rollback row's reason field records exactly which fields were drifted and force-overwritten.

Ancestry Auto-Restore

Reverting a skill file edit on a skill that was later detached or deleted automatically restores the parent skill instance first, then applies the file revert. The drawer surfaces this clearly ("auto-restored parent skill") so you're never surprised.

Sandbox Push

For skill and skill-file reverts, the reverted content is pushed best-effort to your running sandbox so the agent immediately sees the rolled-back version on its next action. This step is non-fatal — if the sandbox is asleep or unreachable, the DB revert still succeeds and the file syncs on the next wake-up.

No-Op Reverts

If the entity is already at the target value (e.g., a later edit already restored it, or two opposing edits cancelled out), the revert is treated as a no-op. You'll see a friendly "already at target" message instead of a fake-success toast, and no rollback row is written.

Rollback Rows

Every successful revert writes a new entry to the timeline with source: rollback. Its reason field links back to the original entry's ID and notes any drift or ancestry restoration that happened along the way — so the audit trail of "someone reverted X because of Y" is preserved alongside the original change.

Grouping & Timeline

Entries are grouped by date for easy scanning:

• Today — Changes from today
• Yesterday — Changes from yesterday
• This week — Changes from the last 7 days (excluding today/yesterday)
• Older — Grouped by calendar date (e.g., "April 12")

Within each group, entries appear chronologically (newest first) along a connected commit-rail — making it visually clear which changes happened close together.

Retention

How long your change history is kept depends on your plan. Higher tiers retain change-log entries for longer — so you can look back further when reviewing how your agent has evolved or tracking down when a setting changed.

If your timeline only goes back so far, you've likely hit your plan's retention window. Upgrading extends it going forward, and may also bring back recent entries that are still around. See the Billing page for the retention window included with each plan.

Use Cases

Debug Unexpected Behavior

When your agent starts behaving differently, the Change Log is the first place to look. "It was working yesterday" becomes "it was working yesterday, and here's exactly what changed overnight — and here's the revert button."

Verify Agent-Made Changes

When you tell your agent to update a setting in chat, open the Change Log afterward to confirm it did exactly what you asked — and nothing more. The inline before/after preview makes verification instant, and one click rolls anything back.

Review Skill Edits

When your agent improves one of its own skills — rewriting instructions, adding a script, or tweaking a reference file — the Change Log captures it. Open any skill or skill-file entry to see exactly what the agent changed, and revert to the previous version if the new one regresses.

Audit & Accountability

For team-managed agents, the Change Log provides a clear accountability trail: who changed what, when, from which surface (chat, UI, API, sync), and why (via linked chat sessions for agent-initiated changes).

Safe Experimentation

Try an experimental setting, watch how the agent behaves, then click Revert to roll back precisely. No guesswork, no copy-paste, no risk of forgetting the original value.

Tips & Best Practices

• Check the Change Log after onboarding — See exactly what your agent configured for itself during the first conversation
• Use the source badge to triage — A surprising change with source user_ui points to a teammate; settings_manager points to a chat conversation
• Use the Mail & Voice filter when debugging channel-specific behavior — narrows the timeline to communication settings only
• Open the detail drawer for long text fields — The inline preview is compact; the drawer shows the full before/after for instructions, prompts, and other multi-line content
• Trace agent decisions — Agent-initiated entries link back to the originating chat session, so you can see the conversation that led to a change
• Don't fear the Revert button — Drift detection prevents accidental clobbering, and every revert itself becomes a new (revertable) timeline entry
• Pair with Runs — A surprising run result often correlates with a recent configuration change. Sibling sub-tabs make side-by-side investigation easy

What's Next?

• Runs & Scheduling — The other half of History — execution tracking
• Agent Settings — The main surface that feeds Change Log entries
• Mail — Mail configuration changes tracked here
• Schedule — Scheduled job create/update/delete changes tracked here