Faculty Orchestrator Plan — Phases 2–4

For Connor review. This plan intentionally skips a broad audit phase. It starts from the stronger product decision: the current proposal/HCP middle layer is probably the wrong centre of gravity. The desired architecture is Hermes as the live operating surface, deterministic integrations as heartbeat evidence collectors, and faculty skills/subagents as the intelligence layer.

Public review target: https://docs.cforsyth.com/faculty-orchestrator-phase-2-4-plan/

0. Source thesis

Connor's current direction, preserved as operating doctrine:

Our proposal interface and intelligence across the board is kind of shit, and overly deterministic.

Forget the whole proposal system and HCP as is, just delete it and make it redundant.

I’m starting to think the architecture is: human -> telegram hermes -> a whole load of faculties as skills to do work, recall memory, build, etc.

continuous orchestrator hermes -> spawns subagents per faculty that do their thing and make low risk changes, and surface high signal. orchestrator utilises the high signal and takes real action, only asking for approval on high risk, human verification, human enablement, large system changes, everything is fully observable and we reach our truly intelligent goal in a self-improving recursive manor too.

integrations -> with heartbeat cadences storing data in a deterministic fashion

everything else or middle management layers, or proxies just feel like noise and should go.

1. Executive decision

Decision update: do not build the MVP inside Hermes Control Plane. Use HCP only as a temporary source reference while extracting useful collectors/state. The MVP should be a clean Hermes-native implementation with its own small directory, explicit contracts, and no dependency on HCP's proposal DB or control-plane abstractions.

Do not evolve the current proposal system into a bigger proposal system.

Instead, build a Hermes-native faculty orchestrator:

Human / Telegram Hermes
  ↔ always-available Hermes agent with tools, memory, skills, GBrain

Deterministic integrations
  → heartbeat source collectors
  → local evidence stores with provenance

Continuous Hermes orchestrator
  → reads recent evidence + memory + live state
  → spawns faculty subagents
  → lets each faculty apply skillful judgement
  → takes safe low-risk actions
  → asks Connor only for approval, verification, enablement, or genuinely high-leverage questions
  → improves its own faculties, skills, policies, and integrations over time

The core architectural move is to delete middle-management layers by making them redundant, not by ripping them out prematurely.

HCP should become an implementation scaffold that is gradually hollowed out until nothing essential depends on it.

2. Requirements

R0 — Hermes is the centre of intelligence

Hermes, not HCP, must become the primary reasoning/orchestration runtime. The system should use Hermes' existing strengths: prompts, skills, tools, memory, cron, subagents, GBrain access, Telegram interface, and action execution.

R1 — Integrations stay deterministic

Integrations should collect and store data on heartbeat cadences. They should not be creative, interpretive, or autonomous beyond source-specific collection, dedupe, provenance, freshness, and health.

R2 — Faculties are skills first, subagents when useful

Each faculty should exist as a Hermes skill with a clear input contract, output contract, judgement policy, examples, pitfalls, and self-improvement loop. For high-context runs, the orchestrator should spawn subagents using those skills.

R3 — Proposal UX is replaced, not polished

The current proposal system should not be treated as the long-term interface. It may be used temporarily as a compatibility layer, but the target UX is an agent manager / approval surface where Hermes explains, acts, asks, and proves done.

R4 — Low-risk work happens automatically

The orchestrator should be allowed to take reversible, low-risk, observable actions without asking Connor every time: file local notes, write candidate artifacts, update skills under review, suppress noise, produce local summaries, run safe checks, and draft proposals.

R5 — High-risk work is gated

The orchestrator must ask for approval or enablement before irreversible, sensitive, expensive, externally visible, or trust-boundary-crossing actions: sending messages, modifying calendar/email/finance, deleting important state, publishing sensitive docs, changing core system architecture, spending money, or granting new permissions.

R6 — Everything is observable

Every orchestrator tick and faculty run must leave reviewable artifacts: evidence read, faculty outputs, actions taken, questions asked, suppressed items, memory writes, skill changes, and proof paths.

R7 — Self-improvement is first-class

The system must improve into its faculties over time:

discernment → per-source filter library
focus → attention / Open Tabs prioritisation
knowledge → GBrain + memory policy
pattern recognition → synthesis over GBrain and evidence stores
creativity → generation patterns and artifact templates
competence → Hermes skills and execution playbooks
conscientiousness → autonomy policy, care loops, and interruption thresholds
self-healing → failure classifiers and repair playbooks
self-upgrading → feature/integration/skill opportunities
self-expanding → scope boundary detection and explicit expansion proposals

R8 — Deletion and simplification are core behaviours

The system should actively identify redundant layers, stale crons, duplicate stores, unused proposal types, noisy digests, dead scripts, and obsolete interfaces. Simplification should be treated as a high-leverage action, not cleanup.

3. Non-goals

Do not build a bigger deterministic proposal taxonomy as the destination.
Do not make every source write directly to every other system.
Do not create another dashboard that Connor must manage.
Do not dump raw private data into GBrain or Telegram.
Do not let subagents mutate high-risk systems without approval.
Do not delete HCP immediately while it still holds useful source connectors, DB state, or scripts.
Do not force everything into JSON schema if Markdown/folder contracts are more expressive and inspectable.

4. Target architecture

4.1 Runtime topology

                           ┌────────────────────────────┐
                           │ Connor via Telegram Hermes │
                           └──────────────┬─────────────┘
                                          │
                                          ▼
                            ┌─────────────────────────┐
                            │ Hermes live agent       │
                            │ tools + skills + memory │
                            └────────────┬────────────┘
                                         │
             ┌───────────────────────────┼───────────────────────────┐
             │                           │                           │
             ▼                           ▼                           ▼
  ┌─────────────────────┐     ┌──────────────────────┐     ┌─────────────────────┐
  │ deterministic        │     │ continuous Hermes     │     │ GBrain / memory      │
  │ integrations         │     │ orchestrator          │     │ durable knowledge    │
  │ heartbeat collectors │     │ prompt.md + skills    │     │ synthesis + recall   │
  └─────────┬───────────┘     └──────────┬───────────┘     └──────────┬──────────┘
            │                            │                            │
            ▼                            ▼                            ▼
  ┌─────────────────────┐     ┌──────────────────────┐     ┌─────────────────────┐
  │ local evidence       │     │ faculty subagents     │     │ learned skills /     │
  │ stores + provenance  │     │ per high-context run  │     │ policies / filters   │
  └─────────────────────┘     └──────────────────────┘     └─────────────────────┘

4.2 The system boundary

The future system has three layers only:

Hermes as agentic interface and orchestrator - Telegram, CLI, cron, tools, skills, subagents, memory.
Evidence stores as deterministic substrate - Integration-specific local stores, source ledgers, files, SQLite/Postgres, raw artifacts, freshness state.
Durable meaning and learned ability - GBrain pages/facts/timeline/synthesis, Hermes skills, source filters, autonomy policies, proof artifacts.

Everything else must justify itself or become redundant.

5. Faculty scope

Each faculty should start as a Hermes skill. A faculty can later become a subagent role, cron worker, or explicit command, but the skill is the canonical behaviour contract.

F1 — Integration Scout

Signal: high signal for new sources of integration.

Looks for:

things Connor keeps manually pasting or asking about;
repeated missing context;
repeated “if only you could see X” moments;
recurring source names in Telegram/GBrain/Open Tabs;
data streams that would reduce human cognitive load.

Outputs:

integration candidate;
source value hypothesis;
privacy/risk class;
MVP collection method;
enablement needed from Connor;
deletion/simplification opportunity if the source replaces an existing proxy.

Self-improves through:

accepted/rejected integration suggestions;
source usefulness after integration;
manual prompts that would have been unnecessary if the source existed.

F2 — Signal Radar Faculty

Signal: high signal from integration context.

Looks for:

external changes that matter to Cloop, Connor, investments, product, research, AI, market, people, or competition;
repeated external themes;
novel edge signals;
anomalies across market-awareness, Gmail newsletters, X/public web, docs, GitHub, and other sources.

Outputs:

signal candidate;
why now;
source citations;
related GBrain entities/concepts;
recommendation: ignore, watch, save, research, act.

Self-improves through:

false-positive suppressions;
source filter updates;
accepted signals that later mattered.

F3 — Focus / Open Tabs Faculty

Signal: high signal for human cognitive load and focus.

Looks for:

active decisions;
stale commitments;
context Connor is carrying manually;
deadlines;
repeated emotional/cognitive load;
“this should be a tab” moments;
tabs that should be closed, merged, reframed, or promoted.

Outputs:

One Thing candidate;
open tab create/update/close suggestion;
now/later/defer/archive recommendation;
“thing to ignore”;
cognitive load reduction proposal.

Self-improves through:

open-tab decisions;
completed/deferred/ignored outcomes;
Connor feedback on whether the brief was actually useful.

F4 — Knowledge / GBrain Faculty

Signal: high signal for current save and future recall.

Looks for:

stable facts;
preferences;
commitments;
original thinking;
entity mentions;
durable project context;
claims that should be timeline entries;
memory entropy or contradiction.

Outputs:

GBrain candidate page/fact/timeline entry;
hot memory candidate;
entity link/stub candidate;
stale/contradictory memory warning;
“do not remember” suppression reason.

Self-improves through:

memory acceptance/rejection;
recall usefulness;
contradiction and drift audits;
memory policy patches.

F5 — Pattern Recognition / Synthesis Faculty

Signal: high signal for connections.

Looks for:

themes across GBrain, Open Tabs, audio, Gmail, market signals, and current conversation;
repeated friction;
converging interests;
contradictions;
strategic drifts;
latent projects;
“this is the same pattern as X”.

Outputs:

synthesis note;
concept update;
cross-link suggestions;
pattern-backed recommendation;
“this deserves a doc” candidate.

Self-improves through:

synthesis pages that prove useful later;
Connor corrections;
pattern recurrence metrics.

F6 — Proposal / Agent Manager Faculty

Signal: high signal for work, research, additions, recommendations, optimisations, or solutions where human-in-the-loop matters.

This replaces the current proposal system.

Looks for:

action candidates;
research/build/delegate opportunities;
system simplifications;
recommendations needing approval;
cases where Hermes can do the work but Connor should choose direction.

Outputs:

agent-manager card;
action owner: Hermes, Connor, joint, external;
risk/reversibility;
acceptance criteria;
proof path;
approval options.

Self-improves through:

approval/rejection/edit outcomes;
“too noisy” feedback;
done-proof quality.

F7 — Procedural Memory / Skills Faculty

Signal: high signal for current document and future use.

Looks for:

repeated workflows;
hard-won debugging discoveries;
user corrections;
brittle procedures;
missing skill docs;
obsolete skill instructions.

Outputs:

new skill candidate;
skill patch candidate;
skill deletion/merge candidate;
procedure-to-skill conversion.

Self-improves through:

skill reuse;
failure after skill use;
Connor corrections;
successful execution patterns.

F8 — Execution Faculty

Signal: high signal for action.

Looks for:

tasks Hermes can safely complete;
tasks requiring goal contracts;
tasks requiring subagents;
tasks requiring external approval;
verification paths.

Outputs:

direct low-risk action;
goal contract;
delegated subagent run;
verification artifact;
blocker/question if needed.

Self-improves through:

action success/failure;
verification quality;
new execution playbooks;
rollback lessons.

F9 — Self-Improving Faculty

Signal: high signal for modifying own faculties.

Looks for:

bad faculty decisions;
stale faculty prompts;
missing examples;
repeated misclassification;
skill gaps;
policy gaps;
opportunity to simplify/merge faculties.

Outputs:

faculty skill patch;
prompt update candidate;
autonomy threshold adjustment;
example library update;
deletion/merge proposal.

Self-improves through:

faculty performance reviews;
before/after metrics;
Connor feedback.

F10 — Self-Healing Faculty

Signal: high signal for failures.

Looks for:

failed crons;
broken services;
ingestion stalls;
stale data;
repeated exceptions;
delivery failures;
degraded system health.

Outputs:

low-risk repair action;
incident summary;
durable fix candidate;
skill/playbook patch;
escalation if risky.

Self-improves through:

repair success rate;
recurrence reduction;
better detection thresholds.

F11 — Self-Upgrading Faculty

Signal: high signal for new features.

Looks for:

features Connor keeps requesting;
platform/tool capability gaps;
new Hermes/GBrain/CLI abilities;
source integration opportunities;
UX improvements.

Outputs:

feature candidate;
build-vs-delete-vs-simplify recommendation;
implementation slice;
risk and value estimate;
dependency list.

Self-improves through:

shipped feature utility;
abandoned feature lessons;
simplification wins.

F12 — Question / Knowledge Gap Faculty

Signal: high signal for gaps in knowledge.

Looks for:

uncertainty that blocks useful action;
missing preferences;
ambiguous commitments;
unclear authority;
unknown source availability;
unknown risk tolerance.

Outputs:

one concise question;
why it matters;
default assumption if unanswered;
possible answer choices if helpful.

Self-improves through:

fewer unnecessary questions;
better defaults;
remembered answers.

F13 — Self-Expanding Faculty

Signal: high signal for scope increase.

Looks for:

a new domain becoming relevant;
current faculties being insufficient;
need for a new integration, skill, policy, or agent role;
“this is bigger than the current frame”.

Outputs:

scope expansion candidate;
new faculty/source/skill proposal;
risk of expansion;
simplification tradeoff;
approval request if expansion changes system boundaries.

Self-improves through:

expansion outcomes;
deleted expansions;
scope creep suppression.

6. Phase plan

Connor requested Phase 2, Phase 3, and Phase 4. This plan therefore treats Phase 1 as already conceptually accepted and focuses on building the agentic path.

Phase 2 — Evidence bundle and deterministic integration heartbeat

Objective: make integrations simple, deterministic, and boring. They collect evidence; they do not decide meaning.

Deliverables

integrations/ registry file - source id; - cadence; - command; - privacy tier; - raw store path; - freshness check; - allowed automatic actions; - human enablement needed.
orchestrator_context.py - reads recent evidence from existing stores; - reads GBrain salience/recent changes; - reads Open Tabs state; - reads recent cron outputs; - reads Signal Radar/market-awareness local output; - reads audio proposal/current transcript summaries; - outputs a compact Markdown evidence packet.
Evidence packet format - Markdown-first, not JSON-first; - citations/path references; - sectioned by source and time window; - explicit freshness/failure notes; - explicit privacy warnings.
Heartbeat simplification - current deterministic scripts become source collectors only; - noisy Telegram delivery is removed unless a watcher detects an actual exception; - source-material outputs go local by default.

Acceptance criteria

A single command produces evidence.md for the last 4–24 hours.
Evidence packet includes source paths and timestamps.
No agent judgement is required to collect the packet.
No new Telegram noise is introduced.
At least Gmail/Google, Open Tabs, GBrain, Signal Radar, cron outputs, and audio-memory are represented.
The packet is small enough for a Hermes orchestrator run.

Deletion/simplification criteria

A collector becomes eligible for deletion or demotion when:

its output is fully replaced by another collector;
its Telegram surface is redundant with the orchestrator brief;
it has failed repeatedly without producing useful signal;
it exists only to compensate for the old proposal/HCP layer.

Phase 3 — Hermes-native orchestrator with prompt.md + faculty skills

Objective: create the continuous orchestrator as a real Hermes agent run, not a deterministic classifier.

Deliverables

Directory:

/root/hermes-control-plane/agents/personal-orchestrator/
  prompt.md
  evidence_contract.md
  action_policy.md
  faculty_roster.md
  output_contract.md
  runs/

prompt.md - defines the orchestrator mission; - forbids dump-like summaries; - requires faculty subagent delegation when context is large; - requires low-risk action where appropriate; - requires approval only for high-risk work; - requires deletion/simplification suggestions; - requires proof artifacts.
Faculty skills - create initial Hermes skills for F1–F13; - each skill contains: trigger, inputs, output shape, examples, allowed actions, forbidden actions, self-improvement loop.
Orchestrator runner - cron or script invokes Hermes with the prompt and selected skills; - first mode is local-only; - output goes to run folder; - Telegram receives nothing unless a high-signal threshold is met.
Run artifact structure

runs/YYYY-MM-DDTHHMMSSZ/
  evidence.md
  orchestrator.md
  faculty/
    integration-scout.md
    signal-radar.md
    focus-open-tabs.md
    knowledge-gbrain.md
    pattern-synthesis.md
    proposals-agent-manager.md
    procedural-skills.md
    execution.md
    self-improving.md
    self-healing.md
    self-upgrading.md
    questions.md
    self-expanding.md
  actions.md
  questions.md
  suppressions.md
  simplifications.md
  proof.md

Acceptance criteria

Orchestrator can run locally from prompt.md and an evidence packet.
At least 5 faculty skills are loaded in the first pass: Focus, Knowledge, Pattern, Proposal/Agent Manager, Self-Healing.
The orchestrator produces fewer than 7 surfaced items per run.
The orchestrator always includes “what to ignore / suppress”.
The orchestrator can identify at least one redundant/noisy surface or confirm none.
No high-risk mutation occurs without approval.
Low-risk changes are recorded with proof.

Deletion/simplification criteria

Once the orchestrator proves it can generate better outputs:

deterministic proposal Telegram summaries become redundant;
individual daily digests that duplicate orchestrator output are demoted to local source material;
HCP proposal generation becomes compatibility-only;
old scripts are wrapped as collectors or deleted.

Phase 4 — Subagent faculties and agent-manager UX

Objective: make the faculties context-rich and genuinely capable by using subagents where large context streams exceed a single orchestrator pass.

Deliverables

Faculty subagent contracts - each faculty gets a goal-shaped prompt; - each subagent gets only the relevant evidence slice plus GBrain/search access as needed; - each subagent returns a concise artifact with citations and recommended actions.
Orchestrator delegation protocol

orchestrator reads evidence.md
  → chooses which faculties need subagents this tick
  → dispatches subagents with faculty skill/context
  → reads faculty outputs
  → resolves conflicts
  → decides action / ask / ignore / remember / simplify
  → writes proof

Agent Manager UX v0 - not the old proposal inbox; - a concise Telegram approval/action surface; - grouped by: Hermes can do, Connor decision, joint enablement, system simplification, question; - every item includes: why this matters, source evidence, risk, done condition, approval options.
Feedback loop - approved/rejected/edited/ignored decisions update faculty examples; - repeated feedback updates filters or skills; - bad recommendations generate self-improvement tasks.
Skillifying faculties - every faculty run can propose skill patches; - self-improving faculty reviews those patches; - low-risk documentation/example updates can be made automatically but surfaced in proof; - behavioural changes to autonomy/risk need approval.

Acceptance criteria

Orchestrator uses subagents only when the evidence/context justifies it.
Faculty outputs cite evidence paths and memory context.
Agent Manager UX can replace the current proposal inbox for at least one source class.
Feedback from Connor changes future recommendations.
The system can propose deletion/simplification of one redundant layer with evidence.
The system can identify a skill gap and create or patch a skill candidate.

7. Phase 5 and Phase 6 preview

These are not the requested build phases, but they frame the deletion path.

Phase 5 — Safe action and competence expansion

Allowlisted low-risk actions.
Goal contracts for meaningful work.
Verified execution proofs.
Skill creation/patching from successful workflows.
Self-healing runbooks.

Phase 6 — Interface revisit and HCP redundancy/deletion

At Phase 6, revisit the interface and architecture from first principles.

Decision question:

Which parts of HCP still do something that Hermes + deterministic collectors + GBrain + skills cannot do more simply?

If none, delete or archive HCP.

Potential end state:

HCP removed
  → deterministic collectors live under small source-specific scripts/services
  → Hermes orchestrator owns intelligence
  → GBrain owns durable meaning
  → skills own learned procedures/faculties
  → Telegram/CLI/docs own interface

Deletion must be evidence-backed:

source connectors migrated;
useful data exported or archived;
crons moved or removed;
docs updated;
old DB made read-only archive;
no live cron depends on deleted paths;
rollback path exists.

8. Implementation slices

Revised implementation root: use a clean MVP outside HCP internals.

Recommended root:

/root/personal-orchestrator/
  README.md
  agents/personal-orchestrator/
  collectors/
  faculties/
  runs/
  state/
  docs/

HCP may be read during migration, but new code should not depend on HCP's proposal DB, schema, CLI, or runtime loop.

Slice 2A — Evidence packet MVP

Goal: produce one coherent Markdown evidence packet from existing systems.

Files:

Create: /root/personal-orchestrator/agents/personal-orchestrator/evidence_contract.md
Create: /root/personal-orchestrator/collectors/orchestrator_context.py
Create: /root/personal-orchestrator/runs/.gitkeep

Verification:

cd /root/personal-orchestrator
python3 collectors/orchestrator_context.py --window 24h --out /tmp/evidence.md
wc -c /tmp/evidence.md
grep -q "Open Tabs" /tmp/evidence.md
grep -q "GBrain" /tmp/evidence.md
grep -q "Signal" /tmp/evidence.md

Slice 2B — Collector simplification map

Goal: classify existing scripts as collector, brief, watchdog, obsolete, or candidate-delete.

Output:

/root/personal-orchestrator/docs/collector-simplification-map.md

This is not a broad audit. It is a deletion/simplification map tied only to the orchestrator migration.

Slice 3A — Orchestrator prompt.md

Goal: define the Hermes-native orchestrator mission.

Files:

Create: /root/personal-orchestrator/agents/personal-orchestrator/prompt.md
Create: /root/personal-orchestrator/agents/personal-orchestrator/action_policy.md
Create: /root/personal-orchestrator/agents/personal-orchestrator/faculty_roster.md
Create: /root/personal-orchestrator/agents/personal-orchestrator/output_contract.md

Verification:

Prompt explicitly says: no dump summaries, surface fewer than 7 items, include suppressions, cite evidence, take low-risk actions, ask only when needed.
Action policy separates low-risk, approval-required, and forbidden actions.

Slice 3B — First five faculty skills

Goal: create the first faculty skills as actual Hermes skills.

Initial faculties:

Focus / Open Tabs
Knowledge / GBrain
Pattern Recognition / Synthesis
Proposal / Agent Manager
Self-Healing

Verification:

hermes skills list | grep -E "focus|knowledge|pattern|agent-manager|self-healing"

Each skill must include:

trigger conditions;
inputs;
output contract;
allowed actions;
forbidden actions;
examples;
self-improvement mechanism.

Slice 3C — Local-only orchestrator cron

Goal: run the orchestrator without Telegram delivery until quality is proven.

Cron:

name: personal-intelligence-orchestrator-local
schedule: every 240m or daily during calibration
deliver: local
skills: first five faculty skills + GBrain/Open Tabs/market-awareness skills
context script: evidence packet builder

Verification:

run folder is created;
output is non-empty;
no Telegram noise;
no high-risk action.

Slice 4A — Subagent faculty protocol

Goal: let the orchestrator spawn subagents per faculty for high-context runs.

Files:

Create: /root/personal-orchestrator/agents/personal-orchestrator/subagent_protocol.md
Create: /root/personal-orchestrator/agents/personal-orchestrator/faculty_prompt_templates/

Verification:

at least two test faculty subagent prompts are runnable;
outputs are concise, cited, and conflict-resolvable by orchestrator.

Slice 4B — Agent Manager UX v0

Goal: replace the old proposal inbox for one source class.

Start with one source class:

Open Tabs, or
Signal Radar, or
Gmail-derived evidence.

Output format:

## Agent Manager
Hermes can do:
- ... [Approve] [Ignore] [Edit]

Connor decision:
- ... [A] [B] [Defer]

Joint enablement:
- ... what I need from you

Simplify/delete:
- ... redundant thing and why

Questions:
- one question max unless critical

Verification:

fewer items than current proposal inbox;
every item has evidence and done condition;
actions are risk-classed;
feedback can be recorded.

9. Risk controls

Low-risk automatic actions

Allowed by default if logged:

write local run artifacts;
create candidate Markdown notes;
update local source-material summaries;
suppress duplicate/noisy notifications;
run health checks;
draft skill patches for review;
create deletion candidates;
create local docs;
query GBrain/Open Tabs/source stores.

Approval-required actions

Require Connor approval:

send external messages;
mutate calendar/email/finance;
publish sensitive or private content;
delete major subsystems or data;
change Hermes autonomy policy;
add broad new data integrations;
change credentials/scopes;
spend money;
run destructive commands;
promote uncertain private claims into canonical memory.

Forbidden without explicit one-off instruction

autonomous money movement;
broad raw private-data publication;
auto-sending legal/work/financial messages;
destructive deletion without archive/rollback;
credential exposure;
treating third-party private messages as Connor's beliefs.

10. Review questions for Connor

Should the first orchestrator run be every 4h, daily, or manual-only while calibrating?
Which first source class should Agent Manager UX replace: Open Tabs, Signal Radar, or Gmail-derived evidence?
Should faculty skill patches be auto-applied when low-risk, or always staged for review initially?
What is the maximum number of surfaced items per orchestrator run? Proposed default: 5.
Should HCP be frozen immediately except for migration/simplification work, or continue receiving small improvements until Phase 6?
Which actions do you want considered low-risk enough for automatic execution from day one?

11. Definition of done for this plan

This plan is accepted when Connor agrees the target architecture is:

Hermes as intelligence + interface
Deterministic integrations as evidence heartbeat
Faculty skills/subagents as judgement and work engines
GBrain as durable meaning
Skills as procedural memory
Minimal/no HCP middle-management layer by Phase 6

And the next implementation commitment is:

Build evidence packet MVP.
Write orchestrator prompt.md and action policy.
Create first five faculty skills.
Run local-only orchestrator.
Replace one proposal surface with Agent Manager UX v0.
Start deleting/demoting redundant middle layers once replacement is proven.