Farther Shore Agent

The Farther Shore Operator is a platform-run agent for a live business. It is not the coding agent working in your repository. It observes a bounded business view, produces evidence-backed findings, and can take only catalogued actions that have been enabled for its role.

The Operator is off by default and enabled per business.

What the Operator can do#

On a run, the Operator may read product metadata, accepted plans and routes, subscription and usage aggregates, revenue indicators, churn, and earlier snapshots. It composes analysis, checks its own evidence, and posts findings, warnings, or product-change requests to the Bulletin.

Most output is advisory. A requested route, plan, pricing, meter, or limit change is a handoff to the coding agent because business/ remains repository-owned.

Customer-facing effects use a closed action catalog. An action runs only when:

1. its capability exists in the catalog;
2. the business has enabled the action gate;
3. the Operator has the exact permission;
4. the payload and audience pass governance validation;
5. Core records the intent and idempotency identity before executing it.

Enabling the Operator does not enable customer messaging. Outward actions are separate and default closed.

Enable and inspect#

farthershore agents list <business> --format json
farthershore agents status <business> --format json
farthershore agents enable <business> --format json
farthershore bulletin list <business> --format json

Use the run id from status to inspect a durable run:

farthershore agents runs-show <business> <runId> --format json

A run records status, composed launches, token usage, trace summary, catalog changes, and action receipts. Authorization decisions are audit events and writes use idempotency keys.

Review and hand off work#

farthershore bulletin show <business> <postId> --format json
farthershore bulletin ack <business> <postId> --format json
farthershore bulletin resolve <business> <postId> --format json

• A contract change request goes to the managed repository.
• A customer-operation suggestion goes through the matching CLI command and its confirmation boundary.
• A surprising effect should be traced through the run receipt and audit log before another write is attempted.

Failure and recovery behavior#

The dispatcher prevents overlapping runs. Lost or silent runs become stale. Three consecutive failed or degraded runs set needsAttention and pause later dispatches. Inspect the trace and action receipts before re-enabling the Operator.

Disable immediately when no more runs or agent-work accrual are wanted:

farthershore agents disable <business> --format json
farthershore agents status <business> --format json

Disabling prevents new runs and further Operator work. It does not delete Bulletin posts, prior run evidence, action receipts, or usage history.

Verification checklist#

• status shows the expected enabled/disabled state;
• no overlapping run is active;
• each surprising action has a matching receipt and audit decision;
• contract change requests are handed to the coding agent rather than applied imperatively;
• Bulletin items are acknowledged or resolved only after their evidence is reviewed.

See Observe and troubleshoot, Customer operations, and Ownership boundaries.