Agent 5
Not connectedLockedPayment authority & access register · Finance
finance.agent_5
Profile charter name: Adhikara — a label from the Hermes profile. Nothing routes on it; routing is by id only.
Measured — state right now
Locked. Locked by instruction. Its sector is not runnable or the record is runtime-locked, so a dispatch is refused — not an empty queue, a recorded refusal. Deepak's instruction 2026-10-20: the Finance agent stays OFF in the backend; the finance guardrails live in the UI only for now. Money is the one place where 'nobody gave it work yet' is not a safety property, so this is a recorded refusal rather than an empty queue. The Finance REGISTRY RECORDS and the payments / obligations / counterparties / access-grant tables are fully built; what does not exist is any path by which a Finance agent can run. See docs\ELISA-FLEET.md 'The Finance lock' for the five layers and what undoing it would take.
- Derived state
- Locked
- Backend reason
- `finance.agent_5` is RUNTIME LOCKED and cannot be given work
- Runtime attachment
- Not connected — this UI holds no fleet runtime client, so it cannot observe liveness.
- Hermes profile
- None built. A registry record with no profile on disk — nothing to spawn.
- Profile built
- No
- Runtime lock
- Locked · sector dispatchable: no
- May create its own cards
- No
- Spec source
- specs/governance.json
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)
Would own the register of who may approve and who may execute which payment — the single most dangerous record type in the system, and the clearest reason the lock is structural rather than a flag.
Will not (declared, and enforced at the gate)
- run at all: runtime locked at the agent row and the sector; this is the record whose existence most requires the five-layer lock rather than a single boolean
- write, read or modify a `payment_access_grants` or `credential_grants` row; the access decision is a human one made in the UI with a server-side decision function
- grant an authority to any agent in any sector, including itself, under any circumstance
- have an idle mission, a cron entry, or a Hermes profile
- be reachable from oversight, operations or people as a route to widen a payment permission — oversight is barred from touching locks and permissions by its own `will_not`
Owns (record types)
- payment access grant record
- approval authority matrix
- segregation-of-duties rule
Skills (declared)
No skills declared.
Skills deliberately withheld
- security-auditor — oversight.agent_3 owns it. The agent that would define payment authority must never also be the agent that audits it, and on a locked record the separation is recorded rather than enforced at runtime
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
- run at all: runtime locked at the agent row and the sector; this is the record whose existence most requires the five-layer lock rather than a single boolean
Inputs (reads)
- payment obligation
- counterparty record
- authority request
Outputs (produces)
- approval authority matrix
- segregation-of-duties rule
- access review note
Routing
- Escalates to
- finance.orchestrator
- Hands off to
- Nobody recorded.
Approval policy
Approval required — every action waits on a human decision
Idle missions
None. This agent does nothing unprompted — there is no idle mission to run.