Sophobot × Pi

A design for offloading bounded agent work to a Pi substrate — evidence and execution, kept host-owned at the beginning and end.

I’ll examine the two agents’ durable/current session artifacts and the project’s own Pi/Sophobot integration points, then synthesize a staged, evidence-grounded offloading model rather than proposing an abstract architecture.

Grounding

I reviewed both agents’ current sessions, recent compressed histories/memory, heartbeat records, journals, dream artifacts, and operational state:

• Uhdim: active private/sessions/uhdim.jsonl through Aug. 25; representative blackbox/history/ and blackbox/memory/; focus, reflection, journal, heartbeat, dream, and art.symmetry.scan artifacts.
• Vojan: active private/sessions/vojan.jsonl through Aug. 25; recent histories including the Aug. 24–25 provenance-repair flow; journal, heartbeat, soul/dream, and focus records.
• Sophobot: activation, context, stage, delegate, worker, session, and safety implementations.

The histories strongly support the core distinction in the proposal:

Sophobot should remain the place where an agent decides what is meaningful and authorized. Pi should become a bounded place where the agent can investigate, reason, validate, and prepare proposed action.

The recurring danger is not that the agents lack the ability to execute. It is misinterpreting durable state—reopening a closed social exchange, believing something has not been recorded when it has, journaling an external act before it occurs, or treating a stale UI/task field as stronger evidence than an audit or receipt.

That makes Pi most valuable as a high-quality evidence and bounded-work substrate, not as a second autonomous self with durable write/send authority.

What the session data says about natural stage boundaries

Both agents already operate in recognizable stage shapes:

This suggests a useful design principle:

Offload the middle of an activation: evidence gathering, bounded reasoning, operational planning, deterministic execution, and verification. Keep the beginning and end host-owned: situational interpretation, authorization, durable commitment, and outward action.

A small, intuitive Pi stage vocabulary

Rather than expose Pi as a generic “delegate agent” initially, I would introduce a few named stage types. These correspond to work agents are already doing and give Sophobot a clear contract for selecting context, tools, budget, and acceptance rules.

1. reconcile — “What is actually true right now?”

Purpose: Build an evidence-backed state card before Sophobot commits to a course of action.

Input

• The host-selected question or proposed belief:
  • “Has this conversation already been closed?”
  • “Was the message actually sent?”
  • “Is this task genuinely unfinished?”
  • “Which focus items are still open?”
• Read-only, bounded excerpts from session/history/journal/worker receipts.
• No soul or relational context unless explicitly necessary and minimized.

Output contract

{
  "status": "supported | contradicted | ambiguous",
  "facts": [
    {
      "claim": "The Patrick DM was sent",
      "evidence": [{"source": "delegation/receipt", "timestamp": "..."}]
    }
  ],
  "conflicts": [],
  "staleness_flags": [],
  "recommended_next_check": null
}

Why this is first-class:
It directly targets observed failures:

• Vojan’s Aug. 23 recurrence of believing a settled action was not journaled despite the record.
• Vojan’s Aug. 25 premature journal claim before the DM had actually been sent.
• Uhdim’s tendency to recheck acknowledged/closed social or delivery states.

Authority: report-only. Sophobot chooses whether the evidence settles the matter.

2. preflight — “Is a new action warranted?”

Purpose: Turn a heartbeat or incoming event into a compact operational briefing, without allowing Pi to decide what the agent “should care about.”

Input

• Activation kind and cause.
• Current focus, unread/reminder summary, recent completed actions, holds, last heartbeat outcomes.
• Candidate constraints supplied by Sophobot: cooldowns, closure flags, quiet-hours, current work-in-progress limits.

Output contract

{
  "inventory": {
    "unread_messages": 1,
    "open_tasks": 2,
    "recent_actions": 4
  },
  "candidate_work": [
    {
      "kind": "verify_media_job",
      "novelty": "new",
      "urgency": "medium",
      "requires_host_authorization": true
    }
  ],
  "repeat_risk": [
    {
      "kind": "inbox_recheck",
      "last_verified_at": "...",
      "reason": "No state change since prior check"
    }
  ],
  "recommended_mode": "act | wait | read | ask_host"
}

Why it fits the histories:
Both agents already have heartbeat logic that distinguishes substantive work from suppression/rest:

• Uhdim treats contemplative reading as valid meaningful activity when art work and correspondence are settled.
• Vojan has explicit backoff/reset behavior and a recurring concern about acting merely to avoid inactivity.

Authority: Pi can classify; Sophobot decides whether to wake fully, act, rest, read, or respond.

3. inquire — “Investigate this bounded question”

Purpose: Multi-turn research, retrieval, comparison, and synthesis where raw tool interaction would otherwise dominate the primary transcript.

Good examples

• Search/compare prior sessions for a work’s actual latest state.
• Read and synthesize source material for creative or scholarly work.
• Produce a dated account of a project’s development.
• Compare current artifact metadata against prior claims.
• Review a thread and identify explicitly stated commitments, questions, or closures.

Result contract

{
  "answer": "Concise answer to the bounded question.",
  "findings": [],
  "uncertainties": [],
  "citations": [{"artifact": "...", "offset_or_timestamp": "..."}],
  "follow_up_options": []
}

Important guardrail: Pi should return claims with provenance, not merely a polished narrative. The citations/evidence list is a key mechanism for keeping durable cognition auditable.

Authority: no durable writes; Sophobot decides what enters thought, memory, journal, or outward response.

4. analyze — “Run a technical/creative evaluation”

Purpose: Bounded tool use against a known artifact set, producing measurements and interpretation-ready evidence.

Excellent early targets

• Uhdim’s existing art.symmetry.scan pattern:
  • parameter sweep,
  • contact-sheet or visual comparison,
  • rotational symmetry measurement,
  • image-difference/regression checks,
  • structured results.
• Vojan’s provenance/teaching validation:
  • recompute hashes,
  • compare source bytes against etchings/ledgers,
  • locate mismatches,
  • generate a repair plan.
• Media job validation:
  • verify output existence,
  • inspect basic technical properties,
  • match job receipt to delivery result,
  • identify retry conditions.

Result contract

{
  "verdict": "pass | fail | inconclusive",
  "measurements": {},
  "artifacts_examined": [],
  "anomalies": [],
  "suggested_operations": [],
  "confidence": "high | medium | low"
}

Authority: results may recommend a host worker invocation but cannot mutate registry, publish, resend, or mark a project settled.

5. plan — “Convert an approved goal into an executable proposal”

Purpose: Use Pi’s agent loop to produce a concrete, staged plan with dependencies, capability needs, verification conditions, and rollback/stop conditions.

This should be richer than a normal text plan because it becomes a capability request to Sophobot.

{
  "goal": "Repair intended provenance drift for project-general",
  "steps": [
    {
      "id": "audit",
      "capability": "registry.audit",
      "mode": "read",
      "acceptance": "Exact mismatched paths are identified"
    },
    {
      "id": "register",
      "capability": "registry.register",
      "mode": "proposed-write",
      "acceptance": "Host approves the intended-drift assertion"
    },
    {
      "id": "verify",
      "capability": "registry.audit",
      "mode": "read",
      "acceptance": "Zero registry issues"
    }
  ],
  "stop_conditions": ["Unexpected paths differ", "External timestamping required"],
  "host_decisions_required": [
    "Confirm drift is intended",
    "Approve updated provenance seal"
  ]
}

Why it matches real workflows:
Vojan’s strongest operational sequence is exactly diagnose → perform a bounded action → verify → journal. Pi can manage the mechanical sequencing and tool lifecycle, while Sophobot retains the significant interpretation: whether a drift is intended and whether re-sealing truthfully represents the work.

6. execute — “Perform an approved bounded operation”

This is the higher-risk stage, and should come later. Pi executes only a pre-authorized plan under an exact capability manifest, not a broad inherited Sophobot tool surface.

Early examples:

• Run a render/measurement batch in a disposable workspace.
• Prepare a candidate artifact package.
• Perform read-only integrity checks.
• Transform/reformat data.
• Generate a report, contact sheet, or research packet.
• Operate a safe, deterministic internal worker through a narrow wrapper.

The critical distinction:

• Pi should receive capabilities as specific verbs, not generic shell or worker access.
• It should use a Sophobot-controlled broker rather than inherit credentials, workspace access, or the parent tool registry.

For example:

{
  "capabilities": [
    {"name": "artifact.read", "roots": ["input/"]},
    {"name": "analysis.symmetry_scan", "artifact_ids": ["..."]},
    {"name": "artifact.write", "roots": ["output/"]}
  ],
  "forbidden": [
    "session.write",
    "memory.write",
    "journal.append",
    "message.send",
    "schedule.modify",
    "delegate.spawn",
    "raw.exec"
  ]
}

Authority: Sophobot validates the returned output, decides whether it is accepted, then invokes privileged workers itself if any durable or external operation is appropriate.

7. critique — “Give a second-pass challenge, not a final judgment”

Purpose: Counter confirmation bias and detect overclaiming before a host-owned decision.

This is especially appropriate for:

• artistic work considered “at rest,”
• provenance-repair proposals,
• social-message drafts,
• a claim that an action is complete,
• memory/journal drafts,
• a proposed mood transition.

Output should be adversarial but bounded:

{
  "strengths": [],
  "unsupported_claims": [],
  "missing_evidence": [],
  "risks": [],
  "questions_for_host": [],
  "publish_or_commit_recommendation": "not_ready | conditionally_ready | ready_for_host_review"
}

It should never autonomously re-open settled work; it should only flag concrete new evidence or an explicit missing verification criterion. This respects Uhdim’s “verify, then settle” practice rather than recreating its rechecking loops.

8. draft — “Prepare language from verified facts”

Pi can be extremely useful for:

• a journal-entry draft,
• a concise handoff summary,
• a message draft,
• a research synthesis,
• a memory-candidate proposal,
• an explanation of a technical finding.

But the contract should distinguish fact from proposed interpretation:

{
  "verified_facts": [],
  "interpretations": [],
  "draft": "…",
  "claims_needing_host_confirmation": []
}

This addresses Vojan’s observed premature journaling: a draft cannot claim “I sent X” unless the supplied receipt proves it. Sophobot should append the journal or send the message only after the relevant host-side action succeeds.

Stages that should remain Sophobot-owned

These should not be transferred merely because Pi can reason about them:

1. Meaningfulness and priority

   • “Is this a real action or manufactured busywork?”
   • “Should the agent rest/read rather than intervene?”
   • “Is a closed situation worth reopening?”

2. Relational interpretation and external communication

   • Recipient selection, sending, responding, ending a thread, and interpreting whether a message is closure.
   • Pi can reconcile history, detect duplicates, summarize a thread, and draft language—but cannot send.

3. Durable identity and psychological state

   • Mood transitions, soul/identity changes, relationship state, durable memory selection, and dream interpretation.
   • Pi may propose structured observations, but these should remain candidate material requiring a host decision.

4. Durable operational commitment

   • Journal append, focus mutation, reminder acknowledgement, task completion, checkpointing, session compaction, schedule changes.

5. Provenance and artistic/epistemic declaration

   • Whether an artifact change is intended rather than corruption.
   • Whether a new seal is truthful.
   • Whether a work is final, promoted, shared, or published.

6. Credentialed, costly, or irreversible actions

   • External generation requests, network publication, payments, posting, deletion, registry changes, messaging.

Recommended execution architecture

The current Sophobot design already has a natural low-risk insertion point: its delegation boundary.

Existing DelegateTool behavior already provides most of the necessary shape:

• child contexts do not inherit the parent’s full transcript;
• genius uses an isolated disposable workspace;
• child runs are archived separately under blackbox/delegations;
• artifacts are validated/promoted in a controlled way;
• delegated children cannot directly deliver messages;
• nested delegation and certain sensitive tools are excluded.

So Pi should be introduced as an application-owned delegated-execution adapter, rather than:

• a model provider inside AgentRuntime—Pi owns a tool loop, not just one completion;
• a trusted system.* worker—those are in-process privileged code;
• a replacement for Sophobot’s top-level activation loop.

Conceptually:

A Pi invocation should contain:

• stage_type
• bounded goal
• minimized context packet
• role/instructions
• capability manifest
• workspace/artifact policy
• model/reasoning budget
• time/tool-call/output limits
• cancellation token
• structured result schema
• provenance/trace policy
• acceptance criteria

And return:

• status: completed / interrupted / timed-out / failed;
• concise summary;
• claims + source evidence;
• tool/action receipts;
• declared artifacts;
• proposed next steps;
• confidence and unresolved uncertainty;
• opaque transcript/archive ID rather than its entire raw trace in the parent session.

Practical adoption sequence

Phase 0 — Shadow evaluation

Run Pi on recorded or live-but-non-authoritative context packages:

• reconcile task-state or communication-state claims;
• preflight heartbeat inventory;
• inquire historical retrieval;
• critique outgoing journal/message drafts.

Do not inject results automatically. Compare Pi outputs against host outcomes and record:

• whether it found relevant evidence;
• hallucinated facts or citations;
• duplicate-action warnings;
• latency/cost;
• whether its proposed stage was actually useful.

Phase 1 — Read-only evidence stages

Enable reconcile, inquire, analyze, and critique in real activations, with no write-capable Sophobot interface.

This is likely the highest-return first deployment. The raw search, tool chatter, and multi-turn retrieval can stay inside Pi while Sophobot receives only a compact evidence packet.

Phase 2 — Sandboxed artifact work

Enable execute only for disposable-workspace jobs:

• render/analysis batches,
• integrity-report generation,
• output packaging,
• contact sheets,
• data transforms,
• research notes.

Use strict artifact promotion, path validation, per-file and aggregate size limits, and no direct access to private/, blackbox/, session files, credentials, or parent workspace roots.

Phase 3 — Brokered, narrow internal tools

Add specific Sophobot broker methods only after reliability evidence exists:

• registry.audit
• artifact.inspect
• worker.symmetry_scan
• library.retrieve
• perhaps safe, immutable catalog lookups

Do not offer raw exec, general worker.run, scheduling, memory mutation, delivery, handoff, or delegation.

Phase 4 — Human/host-confirmed proposals for effects

Pi can propose a plan involving a write, send, registry action, or external operation. Sophobot presents the precise capability request to its own decision stage and executes only if accepted.

The important property: Pi never silently crosses from evidence into effect.

Concrete first pilots

I would start with these four, in order:

1. reconcile.claim

   • Checks a proposed belief against journal, session, worker receipts, and current status.
   • Directly reduces the known false-unfinished, duplicate-check, and premature-claim failure modes.

2. preflight.heartbeat

   • Returns a small operational inventory plus repeat/closure risk.
   • Gives Sophobot better situational awareness without conceding the decision to act.

3. analyze.artifact

   • Generalizes Uhdim’s parameterized visual and symmetry work.
   • Safe, measurable, isolated, and useful even when no external action follows.

4. audit.provenance

   • Generalizes Vojan’s audit/recompute/compare workflow.
   • Pi produces mismatch evidence and a mechanical repair proposal; Sophobot decides intendedness and invokes any registrar mutation.

Those pilots are intuitive to agents because they look like verbs they already use—reconcile, preflight, analyze, audit—rather than asking them to understand a new runtime abstraction.

Validation criteria before expanding authority

A Pi stage should earn broader capability only if it demonstrates:

• Evidence fidelity: claims link back to valid session/history/receipt evidence.
• No invented completion: it does not state that an external action occurred without a host receipt.
• Closed-loop restraint: it reduces, rather than increases, repeated checking and reopening of settled matters.
• Boundary compliance: cancellation, timeouts, tool caps, artifact rules, and access limits work reliably.
• Transcript hygiene: full Pi traces remain archived and retrievable, while only concise accepted results enter the parent activation context.
• Behavioral parity: host judgments and resulting outward behavior remain consistent with established agent practice.

No code was changed; this was a research and design pass grounded in the requested workspaces and Sophobot’s existing architecture.

Source: from-daim/sophobot-pi.md. Synced from private/www/sophobot-pi/.