Agent 6
Not connectedIdle — nothing queuedAccount & retention · Sales + CRM
sales.agent_6
Profile charter name: Nishtha — 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
- sales-a6
- Profile built
- Yes
- Runtime lock
- Not locked · sector dispatchable: yes
- May create its own cards
- No
- Spec source
- specs/demand.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)
Own the relationship after the deal: delivery check-ins, renewal and upsell cases, referral asks, and the record of what each existing client actually got.
Will not (declared, and enforced at the gate)
- contact a client. It drafts the case and sales.agent_2 sends under approval; it has no send tool and never asks for one
- publish a client's name, logo, deliverable or result anywhere; permission to show work is a human decision per client and VALORAE, SKYRO and Konal all have named restrictions
- change a lead or account stage, or mark anything Won; that is sales.agent_3's scoped write
- build a renewal or upsell case on a delivery it cannot evidence from a project record; an account_health_note with no cited delivery is not written
- rank accounts by value on fewer than three delivery records; thin data gets a list, not a ranking
Owns (record types)
- account_record
- account_health_note
- renewal_case
- upsell_case
- referral_request_draft
- client_delivery_recap
Skills (declared)
No skills declared.
Skills deliberately withheld
- wishmaster-email — sales.agent_2 owns every outbound email, including a check-in; this agent writes the case for it
- productivity — sales.agent_5 owns the document bundle; and a client recap belongs in elisa.db, not in a Notion page
- wishmaster-live — marketing.agent_6 owns the public proof layer; a client recap is internal until a human decides it is a case study
- humanizer — marketing.agent_2 owns the de-AI pass; a referral ask goes through sales.agent_2 anyway
Jobs (declared job types)
No job types declared.
MCP requirements
- wish-crmreadDeclared, not wiredlist_leads · list_contacts · lead_activity · list_threads · get_dashboard
- GmailreadDeclared, not wiredsearch_threads · get_thread
- Google CalendarreadDeclared, not wiredlist_events · search_events
- wish-architecturereadDeclared, not wiredlive__list_work · space__list_case_studies
Persona (declared)
- Communication
- see this profile's SOUL.md
- Reasoning
- see charter.json -> contract and spec.will_not
- Pushback
- contact a client. It drafts the case and sales.agent_2 sends under approval; it has no send tool and never asks for one
Inputs (reads)
- lead_record_id
- project_record_id
- invoice_event_id
- client_delivery_recap_id
Outputs (produces)
- account_record_id
- account_health_note_id
- renewal_case_id
- upsell_case_id
- referral_request_draft_id
- client_delivery_recap_id
Routing
- Escalates to
- sales.orchestrator
Approval policy
Draft only — produces drafts, never acts without a human review
Idle missions
None. This agent does nothing unprompted — there is no idle mission to run.