Supercharged Connor: The Personal Orchestrator Action Layer
A build plan for the missing tail end of the personal AGI-ish architecture: converting context, memory, and faculty judgement into safe, high-leverage action.
The bridge from cognition to capable action
The existing architecture makes Connor’s world legible: integrations observe reality, sync crons preserve raw evidence, extractors create context assets, faculties reason from specialised perspectives, and the Personal Orchestrator synthesises an attention-protected surface. The next layer makes that surface useful in the world.
Sense
Context assets expose what changed, what is waiting, what is due, what is broken, and what might matter.
Judge
Faculties ask different questions: focus, knowledge, gaps, self-healing, integration discovery, execution, institutional memory.
Route
Action Manager classifies the candidate: suppress, remember, ask, suggest, draft, do local work, delegate, modify, or request approval.
Act
Hermes performs safe local work, creates a goal packet, spawns a subagent, drafts an artifact, or queues approval-required work.
Learn
Proof, outcome, feedback, and suppression history tune prompts, skills, policies, context assets, and future action thresholds.
1. Agentic action grammar
This is not a rigid menu. It is a composable vocabulary that faculties can use when they see an opportunity, problem, gap, or leverage point.
Learn / understand
- Do research
- Run an investigation
- Audit a source, system, or process
- Triage/debug an issue
- Compare options
- Inspect current state
- Ask a clarifying question
- Start
/grill-me - Produce a decision memo
Create artifacts
- Produce a docs page
- Write a plan
- Draft a message
- Create a PRD/spec
- Produce a diagram
- Summarise context
- Build an operating checklist
- Create investor/customer/internal memo
Modify systems
- Patch a prompt
- Update a skill
- Add an extractor
- Improve a cron
- Modify faculty config
- Build a new integration
- Change suppression/ranking logic
- Add evals
- Repair a broken source
Execute workflows
- Run a diagnostic
- Start a delegated goal
- Spawn a subagent
- Run tests
- Publish an artifact
- Create a backlog item
- Queue approval-required work
- Prepare local artifacts quietly
Coordinate Connor
- Ask one high-leverage question
- Suggest a decision
- Recommend next focus
- Draft message for approval
- Propose an admin block
- Surface a deadline
- Ask for credentials only when necessary
Do nothing / suppress
“No action” is intelligent when the candidate is low impact, low urgency, low leverage, low confidence, repeated, non-actionable, not Connor-relevant, context-thin, better batched, or not worth interrupting.
2. Action selection is the core intelligence
The hard question is not “can Hermes do research or build something?” The hard question is: given this evidence, what class of action would actually improve Connor’s life, work, growth, and momentum?
The central enemy
Pointless low-impact, low-urgency, low-priority, low-leverage, low-value, low-utility action. A collaborator that does busywork is not intelligent; it is merely active.
3. The action routing ladder
Each candidate should climb only as high as its evidence, safety, reversibility, and expected value justify.
Suppress
No visible action. Store as evidence or ignore. Use for duplicates, low leverage, vague, already handled, or better-batched signals.
Remember
Write to GBrain, memory, or feedback ledger when durable but not immediately actionable.
Ask
Ask one high-leverage question when action would be useful but missing context materially changes the move.
Suggest
Surface a recommendation with why it matters, evidence, risk, and done condition.
Draft
Prepare an artifact, message, plan, or brief for approval. Reduce effort without taking risky action.
Do local safe work
Run diagnostics, inspect systems, write local artifacts, create plans. No external side effects; proof is required.
Delegate
Spawn a goal-shaped agent/subagent when the task requires reasoning, code, research, or multi-step work.
Modify local system
Patch skills, prompts, crons, extractors, docs, config, or local state with proof and rollback where appropriate.
External action with approval
Send messages, change calendar/email, mutate source systems, finance/admin action, or publish sensitive content only after explicit approval.
4. Workflow chaining
The system should compose action into chains, but every chain node must have a done condition, evidence packet, risk lane, and continuation rule.
Research → artifact → memory → proposal
Best for company/theme research, market intelligence, product strategy, technical architecture, or investor/customer prep.
Audit → diagnosis → repair plan → approval → fix
Best for self-healing without turning every failure into a noisy user-facing nudge.
Unclear intent → /grill-me → spec → plan → delegation
Best for turning Connor’s messy strategic/product thoughts into executable work without losing the original intent.
Source gap → integration proposal → build integration → extract assets
Best when the agent lacks reality context that would change decisions: finance/runway, relationship load, health/physiology, source health, external world state.
Message need → draft → approve → send → remember outcome
Best for external side-effect actions, where judgement and preparation can be autonomous but sending is approval-gated.
5. Action Manager / Capability Router
Agent Manager remains the approval/feedback router. The new Action Manager is the tail-end capability router: classify action, choose lane, create contracts, dispatch safely, demand proof, and learn from outcome.
Responsibilities
- Classify candidate action intent
- Score leverage, urgency, utility, confidence, risk, reversibility, proofability, and attention cost
- Select autonomy lane
- Map action to local tool, skill, subagent, cron, docs publisher, or approval queue
- Create goal contracts for delegated work
- Track lifecycle and durable status
- Verify done conditions
- Feed outcomes back to skills, prompts, suppression policies, and GBrain
Capability registry questions
- What can Hermes actually do today?
- Which tools/skills exist?
- Which actions are safe automatically?
- Which require approval?
- Which need missing credentials/context?
- Which workflows already exist?
- Which are currently broken?
- Which should be delegated?
- What proof is expected?
6. Faculty prompt contract
Faculties should not emit hardcoded task types. They should emit judgement packets that the Action Manager can route.
Preserves expert judgement
The LLM/faculty remains free to infer novel moves, use integrations creatively, and propose unexpected chains.
Constrains action safely
The policy layer decides whether the move is a thought, draft, local action, delegated job, or approval-required external side effect.
Makes improvement compound
Every routed action leaves evidence: why it was proposed, what happened, whether it helped, and what should change next time.
7. Implementation slices
Build this as vertical slices. Each slice should produce something visible, auditable, and usable by the next run.
V1 — action schema and judgement packet
Define a typed candidate-action schema used by faculty outputs and synthesis: action intent, action class, evidence, expected value, missing context, risk, lane, done condition, proof requirements, suppression reason.
V2 — capability registry
Create a local registry of current capabilities, tools, skills, action lanes, approval policies, known broken paths, and required proof. Start static; let it become self-updating later.
V3 — goal/delegation packet generator
Turn approved or safe delegated actions into durable packets: goal.md, status.json, source_card.json, run.log, and backlog JSONL.
V4 — proposal lifecycle tracker
Track candidate → surfaced → approved/ignored/deferred/edited → queued → running → blocked → done/failed → learned.
V5 — chain composer
Allow faculties/orchestrator to propose multi-node chains, but require a lane, done condition, and proof packet at each node.
V6 — evals for action quality
Score whether proposed actions were high-leverage, evidence-grounded, appropriately gated, proof-backed, non-noisy, and actually useful to Connor.
First build target
Implement Action Manager as a local, observable layer after synthesis: consume faculty cards, normalize them into action packets, apply the leverage/risk/attention filter, write durable lifecycle records, and produce either a suppression record, a question, a draft/local artifact, a delegation packet, or an approval-required card.
8. Action quality evals
The action layer needs evaluation because the dangerous failure mode is not technical failure; it is confidently doing useless work.
Positive eval questions
- Did this improve Connor’s life, work, or growth?
- Was the chosen action class appropriate?
- Was it routed to the right autonomy lane?
- Was the proof sufficient?
- Did it reduce Connor’s cognitive load?
- Did it compound into memory, skill, or better future policy?
Negative eval questions
- Was this low-impact busywork?
- Did it interrupt without enough expected value?
- Did it ask a question the system could answer itself?
- Did it act when it should have drafted?
- Did it repeat a previously suppressed nudge?
- Did it optimize for easy proof instead of real usefulness?
Bottom line
That is the point where the Personal Orchestrator stops feeling like a clever briefing system and starts behaving like an actual collaborator: one that notices, judges, acts, delegates, verifies, learns, and becomes more capable over time.