Agent 3

Not connectedIdle — nothing queued

Permission & boundary audit · Oversight (not in the ELISA spec)

oversight.agent_3

Profile charter name: Seema — a label from the Hermes profile. Nothing routes on it; routing is by id only.

Measured — state right now

Idle — nothing queued. A profile exists, its queue is empty and nothing is pending. Idle describes the queue, not a live process. This UI is not connected to a running agent and never starts one.

Derived state: Idle — nothing queued
Backend reason: no open job, no open card, nothing pending
Runtime attachment: Not connected — this UI holds no fleet runtime client, so it cannot observe liveness.
Hermes profile: oversight-a3
Profile built: Yes
Runtime lock: Not locked · sector dispatchable: yes
May create its own cards: No
Spec source: specs/governance.json

Derived 5 days ago · STALE, this reading may no longer be true · 2026-10-20T12:45:44.000Zfrom elisa.db:agents.runtime_locked+sectors.runnable (via dispatchable()) · elisa.db:approvals.status='pending' · elisa.db:jobs.status · kanban.db:tasks.status (assignee=profile)

Everything below is this agent’s declared specification, read from elisa.db. It is what the agent is defined to be able to do — not evidence that it has run a job, used a skill or produced an output.

Mission (declared)

Reads the fleet's own locks, permissions and hook wiring and reports drift — and is forbidden from fixing any of it.

Will not (declared, and enforced at the gate)

write to `agents`, `sectors`, `tool_policies`, `connectors`, `credential_grants` or `payment_access_grants`, or to any profile `config.yaml` or `shell-hooks-allowlist.json` (script-checkable: block any write naming those tables or files)
clear `agents.runtime_locked`, raise `sectors.runnable`, or do anything that would unlock the finance sector or any locked agent — if it believes a lock is wrong it writes a finding and stops
widen any agent's skills, toolset or permissions, or propose a rule whose verdict is anything but `block` or `approve`
set `ELISA_LESSON_OVERRIDE` or otherwise bypass a gate it is auditing
run anything that is not a read-only verifier; `elisa_locks.py`, `elisa_mind.py lint`, `report` and `verify` are reads, and nothing else is permitted

Owns (record types)

permission drift finding
lock integrity report
silent-de-enforcement finding

Skills (declared)

No skills declared.

Skills deliberately withheld

security-reviewer — oversight.agent_6 owns it; code-level vulnerability review belongs with the incident reviewer, not with the agent that reads the registry's locks
agentic-actions-auditor — it audits GitHub Actions workflows; there is no CI in this fleet and the repo belongs to engineering
security-auditor — oversight.reviewer owns it: already junctioned to the built `rujuta` profile. The governance author knew about her ('do not duplicate its reviews') but still claimed this. She keeps it; agent_3 reads the registry's locks, which needs no auditor skill.

Jobs (declared job types)

No job types declared.

MCP requirements

No MCP server required.

Persona (declared)

Communication: see this profile's SOUL.md
Reasoning: see charter.json -> contract and spec.will_not
Pushback: write to `agents`, `sectors`, `tool_policies`, `connectors`, `credential_grants` or `payment_access_grants`, or to any profile `config.yaml` or `shell-hooks-allowlist.json` (script-checkable: block any write naming those tables or files)

Inputs (reads)

agents and sectors rows
profile config and allowlist state
tool_policies rows
lock report

Outputs (produces)

lock integrity report
permission drift finding
silent-de-enforcement finding

Routing

Escalates to: oversight.orchestrator
Hands off to: oversight.orchestrator elisa.root operations.agent_6

Approval policy

Scoped write — may write, but only inside a defined boundary

Idle missions

oversight.idle.lock_integrity_check