an ops agent of its own — after golive

[mxfactorial]

The operator gerp's bookkeeper investigates alarm tasks today: an alarm lands as a task on its
books (prod/platform/operator/AGENTS.md § the alarm as a task), the insert pokes it, and a
read_fleet_logs tool in the shared agent image — registered only where OPS_READ_ROLE is set,
which prod/per_customer sets for the operator's own gerp — reads the gerp's logs through
gerp-ops-read and the finding goes back on the task. It works, and it is the wrong container.
A bookkeeper's image carries a bookkeeper's persona, the owner's tools, the browser shim, the
gateway to a firm's books; an investigator needs none of that and a different trust. One image
serving two jobs by env switch means every gerp's image carries an operator's tool, the
bookkeeper's prompt has to explain ops to itself, and the operator's investigations spend the
operator gerp's agent budget and sit in its session history.

the shape

An ops agent: its own image, its own runtime, in the platform's account beside the collector.

part	what
the image	agentcore-ops in the operator ECR: a Strands agent whose persona is the operator's runbook — the platform docs (prod/tower/AGENTS.md, prod/hub/AGENTS.md, modules/terraform/AGENTS.md and the module docs) as its knowledge, the way playbooks are the bookkeeper's — and no gateway, no browser, no memory of an owner
the runtime	one AgentCore runtime in the operator account (prod/platform/operator), invoked by the collector after it files a task; its execution role is the operator account's, so gerp-ops-read admits it as it admits a person, with no principal added anywhere
the tools	reads: read_fleet_logs (the task's query, a queue's head), describe_alarms, the edges of a hub (manage_edges list), a table's description; the task door: manage_tasks get / update on the operator gerp, cross-account, the grant the collector already holds; one act: redrive of a parked record, and only that — everything else it proposes on the task and a person does
the poke	issue_collector invokes the runtime with the task id once the task is filed (its own account, no stream, no ESM); a strike on an open task does not re-poke
the budget	a cap on investigations a day in config.json, and the account's Bedrock budget line is the platform's, not a gerp's
the write-back	the same four fields — investigated_by: ops, finding, root_cause, proposed_fix — so a person's finding from scripts/investigate.sh and a managed investigator's sit beside it

what it removes

• the OPS_READ_ROLE switch in prod/per_customer and the tool's registration in the shared
  image — every gerp's image goes back to a bookkeeper's tools
• the operator gerp's runtime role as a principal on gerp-ops-read's trust (prod/init_customer)
• the alarm branch of tasks_poke and its filter entry: a gerp's tasks table pokes its agent
  for escalations and assignments only, and the operator gerp's bookkeeper keeps the operator's
  books and nothing else

The local investigator (scripts/investigate.sh) and the write-back fields stay as they are;
a managed investigator (AWS DevOps Agent, #8) is a third client of the same task and the same role.

the build

• the image — prod/platform/operator/opsagent/ (Dockerfile, entrypoint.py, the
  runbook prompt from the docs at build), pushed by deploy.sh image --ops.
• the runtime — aws_bedrockagentcore_agent_runtime.ops + endpoint in
  prod/platform/operator; the execution role: sts:AssumeRole on gerp-ops-read across the
  organization, lambda:InvokeFunction on the operator gerp's manage_tasks, Bedrock invoke.
• the poke — issue_collector invokes the ops runtime after put, under the daily cap;
  tasks_poke loses its alarm branch and filter entry; prod/per_customer and
  prod/init_customer lose the switch and the principal; the shared image loses the tool.
• the redrive — the one act: the stream module's -failed queue redriven by the ops
  agent's own call, logged on the task; every other fix is a proposal.
• the judgment — DONE-TEST: the same parked-record task worked by the ops agent, a
  person at a terminal, and (after golive) the managed investigator, three findings side by
  side on one task.