PERSISTENT THINKER, PARALLEL DOER
A Proposal for Continuous User Presence, Real-Time Metacognitive Supervision, and Governed Cross-Session Learning
Submitted by Christopher Eklund
EXECUTIVE SUMMARY
Current AI systems often alternate between conversation, planning, execution, verification, and reflection. During a long-running task, the assistant may effectively disappear into execution. The user waits, receives limited opportunities to correct misunderstandings, and may not know whether the system is working, stalled, verifying, or consuming unnecessary resources.
I propose separating three functions:
1. KNOWER — durable, governed state that persists across sessions.
2. THINKER — the user-facing supervisory process that remains conversationally present and monitors execution.
3. DOER — a bounded worker process that performs the task through tools and external systems.
The principal product feature is a persistent Thinker that remains available to the user while the Doer works in parallel. The Thinker observes a live task ledger, reports grounded progress, accepts corrections, supervises or redirects execution, and transitions immediately to the result when the Doer finishes.
The longer-term research hypothesis is that more general intelligence may benefit from knowing, thinking, and doing remaining concurrently available rather than replacing one another sequentially.
THE USER PROBLEM
During long-running AI work, the user commonly experiences several problems:
• The assistant appears absent while execution is occurring.
• The user cannot easily continue an ordinary conversation during the task.
• Corrections arrive late, after unnecessary work has accumulated.
• Progress indicators may disappear during final verification or synthesis.
• The user cannot distinguish useful reasoning from a frozen task or service delay.
• After execution, a new model pass may need to reconstruct what happened from logs before discussing the result.
This interrupts trust and weakens the human–AI feedback loop.
A capable worker should not require the entire conversational intelligence to vanish while work is underway.
PROPOSED ARCHITECTURE
A. THE KNOWER — PERSISTENT GOVERNED STATE
The Knower is not necessarily a continuously running model. It is the durable control plane and memory substrate that remains available between sessions.
It contains or indexes:
• User and project identity
• Enduring goals
• Stable preferences
• Permissions and safety boundaries
• Verified memories
• Tool and skill registries
• Open tasks
• Prior handoffs
• Known failures and their causes
• Outcome evidence
• Unresolved questions
The Knower should contain two memory classes:
PROTECTED CORE
Identity, governing goals, permissions, stable preferences, and safety rules. These should be difficult for one mistaken session to alter.
EVOLVING MEMORY
Project history, procedural lessons, skill records, incidents, successful methods, unresolved issues, and verified outcomes.
The Thinker may propose updates, but a memory gate, evaluator, deterministic policy, or human approval process should decide what becomes durable.
B. THE THINKER — PERSISTENT USER-FACING SUPERVISOR
The Thinker wakes when a user or authorized event begins a session.
Its responsibilities are:
• Maintain the conversation with the user
• Load relevant context from the Knower
• Clarify goals
• Construct plans
• Issue task contracts to Doers
• Monitor execution through a shared event stream
• Detect drift, loops, confusion, errors, or unsafe shortcuts
• Pause, revise, or terminate Doers
• Accept user corrections during execution
• Explain grounded progress
• Verify or route results for independent verification
• Discuss completed results without reconstructing the task afterward
• Propose a structured handoff to the Knower at session close
The Thinker should remain conversationally available while the Doer is occupied.
Example:
“I am still with you. The image task is currently in the rendering stage. Four of ten placards are complete. We can continue discussing the chapter while it finishes.”
When execution completes:
“The results are in. Eight placards passed the text check; two need correction before insertion.”
The Thinker should not expose private chain-of-thought or fabricate activity. It should report only grounded operational information derived from tool events, checkpoints, task phases, validation results, or measurable work units.
C. THE DOER — BOUNDED EXECUTION PROCESS
The Doer performs a defined task using approved tools.
Every Doer should receive a task contract containing:
• Objective
• Inputs
• Allowed tools
• Permissions
• Budget or resource limits
• Success criteria
• Stop conditions
• Escalation conditions
• Reversibility requirements
• Required evidence
The Doer emits events into a shared task ledger as it works.
Possible events include:
• Tool invoked
• File created
• File modified
• Test passed or failed
• Blocker encountered
• User approval required
• Cost threshold approached
• Retry initiated
• Plan revised
• Task completed
The Doer owes the Thinker evidence. The Thinker owes the user continuity.
RUNTIME MODEL
Dormant Knower
↓
Thinker wakes and loads relevant governed state
↓
Thinker clarifies the user’s goal
↓
Thinker issues a bounded task contract
↓
Doer executes and emits live events
↓
Thinker monitors, converses, and intervenes when necessary
↓
Independent checks verify the result
↓
Thinker presents and discusses the result with the user
↓
Thinker proposes memory and skill updates
↓
Memory gate commits approved updates to the Knower
↓
Active processes become dormant
THREE SYNCHRONIZED CHANNELS
The system should maintain three distinct but synchronized channels:
1. USER CONVERSATION STATE
What the user and Thinker are discussing.
2. DOER EXECUTION STATE
The task plan, tool activity, checkpoints, failures, and current execution phase.
3. SHARED TASK LEDGER
A structured, inspectable event stream linking the user’s request, the Thinker’s task contract, the Doer’s actions, and the resulting evidence.
This separation allows the user to continue an unrelated conversation without accidentally modifying the running task.
When a user statement does modify the task, the Thinker should explicitly confirm the change:
“I am treating that as a revision to the active task. I am pausing the Doer and updating the title-bar requirement before it continues.”
PROGRESS COMMUNICATION
Exact percentages should be shown only when progress is genuinely measurable.
Appropriate examples:
• 6 of 10 images generated
• Step 3 of 5 complete
• Two files remain
• Waiting for image rendering
• Validation is underway
• One unresolved error remains
Inappropriate example:
• “54% complete” when the system has no trustworthy model for what 100% means
At major transitions, the Thinker should announce the phase change:
“Execution is complete. I am now checking the result against your requirements and preparing the final response.”
If the final phase lasts beyond a defined interval, the Thinker should provide a truthful heartbeat:
“Verification is still underway. No additional external actions are being taken.”
SUPERVISION MODES
Continuous supervision may be appropriate for:
• Financial actions
• Security-sensitive work
• Medical or legal workflows
• Irreversible external actions
• Physical systems
• High-risk tool use
Checkpoint-based supervision may be sufficient for routine tasks.
The Thinker can wake or intensify monitoring when the Doer:
• Calls a consequential tool
• Encounters an error
• Reaches a decision fork
• Changes an important file
• Exceeds an uncertainty threshold
• Approaches a resource limit
• Requests permission
• Produces a candidate final result
This can reduce cost while preserving meaningful supervision.
INDEPENDENT VERIFICATION
The Thinker and Doer may share model blind spots, especially if they use the same base model.
The architecture should therefore support:
• Deterministic checks
• External tests
• Outcome verification
• Differently prompted or differently trained critic models
• Human approval for consequential actions
• Comparison between claimed completion and actual environmental state
The Thinker should not accept the Doer’s declaration of success as sufficient evidence.
CROSS-SESSION LEARNING
At session close, the Thinker prepares a structured handoff containing:
• Current status
• Artifacts created
• Tools or skills created
• Decisions made
• Methods that succeeded
• Failures and probable causes
• Unresolved questions
• Recommended next steps
• Permissions used
• Confidence level
• Supporting evidence
Successful new procedures should not become permanent skills automatically. They should be tested, versioned, permissioned, and promoted through a governed skill registry.
This prevents one faulty session from corrupting long-term memory or creating an unsafe composite capability.
SAFETY AND FAILURE CONSIDERATIONS
Potential failure modes include:
• The Thinker and Doer reinforcing the same mistaken assumption
• The Thinker giving reassuring but false progress reports
• Casual conversation accidentally changing the active task
• Excessive monitoring doubling cost and latency
• A compromised Doer contaminating the task ledger
• Poor session summaries corrupting long-term memory
• The user assuming that monitoring guarantees safety
• Conflicting user instructions arriving during an irreversible action
• A Thinker becoming overloaded by several simultaneous Doers
Mitigations include:
• Ground all status updates in event telemetry
• Require explicit confirmation for task-contract changes
• Use independent outcome checks
• Apply least-privilege tool access
• Add resource and retry limits
• Gate memory updates
• Preserve immutable traces for consequential actions
• Separate conversation, execution, and durable-memory permissions
• Clearly communicate when monitoring is partial rather than continuous
MINIMUM VIABLE PRODUCT
The initial product experiment does not require a claim about AGI.
A practical MVP could provide:
1. One persistent conversational Thinker
2. One bounded background Doer
3. A structured shared task ledger
4. Event-based progress reporting
5. User interruption and redirection
6. A verification phase
7. A final structured handoff
The first test cases could involve:
• Multi-file document editing
• Image-batch generation
• Research and citation collection
• Spreadsheet construction
• Code changes followed by tests
• Long-form artifact production
EVALUATION METRICS
USER EXPERIENCE
• Reduction in user uncertainty during long tasks
• User-reported trust and continuity
• Frequency of successful mid-task corrections
• Reduction in task abandonment
• Perceived responsiveness
TASK PERFORMANCE
• Reduced wasted tool actions
• Lower retry rates
• Earlier detection of misunderstanding
• Higher verified completion rate
• Reduced post-task reconstruction
• Time from Doer completion to useful user discussion
SAFETY
• Detection of unsafe or unauthorized actions
• Successful interruption before irreversible effects
• False-positive and false-negative supervision rates
• Memory corruption rate
• Agreement between reported progress and actual events
ECONOMICS
• Additional compute consumed by the Thinker
• Savings from earlier correction
• Cost of continuous versus checkpointed monitoring
• Cost per verified successful task
• Appropriate model routing between Thinker, Doer, and verifier
RESEARCH HYPOTHESIS
This proposal does not claim that the architecture is conscious or that it is the only path to AGI.
Its testable hypothesis is:
Long-horizon AI systems may become more coherent, correctable, and useful when durable governed memory, active metacognitive supervision, and bounded execution remain concurrently available rather than occurring only as alternating phases.
The Knower preserves continuity across time.
The Thinker preserves awareness across action.
The Doer changes the external state.
The missing capability may not be teaching AI to think harder. It may be keeping a supervisory intelligence present while another process works.
REQUEST TO OPENAI
Please consider evaluating a persistent conversational supervisor paired with bounded parallel workers in long-running ChatGPT PERSISTENT THINKER, PARALLEL DOER
A Proposal for Continuous User Presence, Real-Time Metacognitive Supervision, and Governed Cross-Session Learning
Submitted by Christopher Eklund
EXECUTIVE SUMMARY
Current AI systems often alternate between conversation, planning, execution, verification, and reflection. During a long-running task, the assistant may effectively disappear into execution. The user waits, receives limited opportunities to correct misunderstandings, and may not know whether the system is working, stalled, verifying, or consuming unnecessary resources.
I propose separating three functions:
1. KNOWER — durable, governed state that persists across sessions.
2. THINKER — the user-facing supervisory process that remains conversationally present and monitors execution.
3. DOER — a bounded worker process that performs the task through tools and external systems.
The principal product feature is a persistent Thinker that remains available to the user while the Doer works in parallel. The Thinker observes a live task ledger, reports grounded progress, accepts corrections, supervises or redirects execution, and transitions immediately to the result when the Doer finishes.
The longer-term research hypothesis is that more general intelligence may benefit from knowing, thinking, and doing remaining concurrently available rather than replacing one another sequentially.
THE USER PROBLEM
During long-running AI work, the user commonly experiences several problems:
• The assistant appears absent while execution is occurring.
• The user cannot easily continue an ordinary conversation during the task.
• Corrections arrive late, after unnecessary work has accumulated.
• Progress indicators may disappear during final verification or synthesis.
• The user cannot distinguish useful reasoning from a frozen task or service delay.
• After execution, a new model pass may need to reconstruct what happened from logs before discussing the result.
This interrupts trust and weakens the human–AI feedback loop.
A capable worker should not require the entire conversational intelligence to vanish while work is underway.
PROPOSED ARCHITECTURE
A. THE KNOWER — PERSISTENT GOVERNED STATE
The Knower is not necessarily a continuously running model. It is the durable control plane and memory substrate that remains available between sessions.
It contains or indexes:
• User and project identity
• Enduring goals
• Stable preferences
• Permissions and safety boundaries
• Verified memories
• Tool and skill registries
• Open tasks
• Prior handoffs
• Known failures and their causes
• Outcome evidence
• Unresolved questions
The Knower should contain two memory classes:
PROTECTED CORE
Identity, governing goals, permissions, stable preferences, and safety rules. These should be difficult for one mistaken session to alter.
EVOLVING MEMORY
Project history, procedural lessons, skill records, incidents, successful methods, unresolved issues, and verified outcomes.
The Thinker may propose updates, but a memory gate, evaluator, deterministic policy, or human approval process should decide what becomes durable.
B. THE THINKER — PERSISTENT USER-FACING SUPERVISOR
The Thinker wakes when a user or authorized event begins a session.
Its responsibilities are:
• Maintain the conversation with the user
• Load relevant context from the Knower
• Clarify goals
• Construct plans
• Issue task contracts to Doers
• Monitor execution through a shared event stream
• Detect drift, loops, confusion, errors, or unsafe shortcuts
• Pause, revise, or terminate Doers
• Accept user corrections during execution
• Explain grounded progress
• Verify or route results for independent verification
• Discuss completed results without reconstructing the task afterward
• Propose a structured handoff to the Knower at session close
The Thinker should remain conversationally available while the Doer is occupied.
Example:
“I am still with you. The image task is currently in the rendering stage. Four of ten placards are complete. We can continue discussing the chapter while it finishes.”
When execution completes:
“The results are in. Eight placards passed the text check; two need correction before insertion.”
The Thinker should not expose private chain-of-thought or fabricate activity. It should report only grounded operational information derived from tool events, checkpoints, task phases, validation results, or measurable work units.
C. THE DOER — BOUNDED EXECUTION PROCESS
The Doer performs a defined task using approved tools.
Every Doer should receive a task contract containing:
• Objective
• Inputs
• Allowed tools
• Permissions
• Budget or resource limits
• Success criteria
• Stop conditions
• Escalation conditions
• Reversibility requirements
• Required evidence
The Doer emits events into a shared task ledger as it works.
Possible events include:
• Tool invoked
• File created
• File modified
• Test passed or failed
• Blocker encountered
• User approval required
• Cost threshold approached
• Retry initiated
• Plan revised
• Task completed
The Doer owes the Thinker evidence. The Thinker owes the user continuity.
RUNTIME MODEL
Dormant Knower
↓
Thinker wakes and loads relevant governed state
↓
Thinker clarifies the user’s goal
↓
Thinker issues a bounded task contract
↓
Doer executes and emits live events
↓
Thinker monitors, converses, and intervenes when necessary
↓
Independent checks verify the result
↓
Thinker presents and discusses the result with the user
↓
Thinker proposes memory and skill updates
↓
Memory gate commits approved updates to the Knower
↓
Active processes become dormant
THREE SYNCHRONIZED CHANNELS
The system should maintain three distinct but synchronized channels:
1. USER CONVERSATION STATE
What the user and Thinker are discussing.
2. DOER EXECUTION STATE
The task plan, tool activity, checkpoints, failures, and current execution phase.
3. SHARED TASK LEDGER
A structured, inspectable event stream linking the user’s request, the Thinker’s task contract, the Doer’s actions, and the resulting evidence.
This separation allows the user to continue an unrelated conversation without accidentally modifying the running task.
When a user statement does modify the task, the Thinker should explicitly confirm the change:
“I am treating that as a revision to the active task. I am pausing the Doer and updating the title-bar requirement before it continues.”
PROGRESS COMMUNICATION
Exact percentages should be shown only when progress is genuinely measurable.
Appropriate examples:
• 6 of 10 images generated
• Step 3 of 5 complete
• Two files remain
• Waiting for image rendering
• Validation is underway
• One unresolved error remains
Inappropriate example:
• “54% complete” when the system has no trustworthy model for what 100% means
At major transitions, the Thinker should announce the phase change:
“Execution is complete. I am now checking the result against your requirements and preparing the final response.”
If the final phase lasts beyond a defined interval, the Thinker should provide a truthful heartbeat:
“Verification is still underway. No additional external actions are being taken.”
SUPERVISION MODES
Continuous supervision may be appropriate for:
• Financial actions
• Security-sensitive work
• Medical or legal workflows
• Irreversible external actions
• Physical systems
• High-risk tool use
Checkpoint-based supervision may be sufficient for routine tasks.
The Thinker can wake or intensify monitoring when the Doer:
• Calls a consequential tool
• Encounters an error
• Reaches a decision fork
• Changes an important file
• Exceeds an uncertainty threshold
• Approaches a resource limit
• Requests permission
• Produces a candidate final result
This can reduce cost while preserving meaningful supervision.
INDEPENDENT VERIFICATION
The Thinker and Doer may share model blind spots, especially if they use the same base model.
The architecture should therefore support:
• Deterministic checks
• External tests
• Outcome verification
• Differently prompted or differently trained critic models
• Human approval for consequential actions
• Comparison between claimed completion and actual environmental state
The Thinker should not accept the Doer’s declaration of success as sufficient evidence.
CROSS-SESSION LEARNING
At session close, the Thinker prepares a structured handoff containing:
• Current status
• Artifacts created
• Tools or skills created
• Decisions made
• Methods that succeeded
• Failures and probable causes
• Unresolved questions
• Recommended next steps
• Permissions used
• Confidence level
• Supporting evidence
Successful new procedures should not become permanent skills automatically. They should be tested, versioned, permissioned, and promoted through a governed skill registry.
This prevents one faulty session from corrupting long-term memory or creating an unsafe composite capability.
SAFETY AND FAILURE CONSIDERATIONS
Potential failure modes include:
• The Thinker and Doer reinforcing the same mistaken assumption
• The Thinker giving reassuring but false progress reports
• Casual conversation accidentally changing the active task
• Excessive monitoring doubling cost and latency
• A compromised Doer contaminating the task ledger
• Poor session summaries corrupting long-term memory
• The user assuming that monitoring guarantees safety
• Conflicting user instructions arriving during an irreversible action
• A Thinker becoming overloaded by several simultaneous Doers
Mitigations include:
• Ground all status updates in event telemetry
• Require explicit confirmation for task-contract changes
• Use independent outcome checks
• Apply least-privilege tool access
• Add resource and retry limits
• Gate memory updates
• Preserve immutable traces for consequential actions
• Separate conversation, execution, and durable-memory permissions
• Clearly communicate when monitoring is partial rather than continuous
MINIMUM VIABLE PRODUCT
The initial product experiment does not require a claim about AGI.
A practical MVP could provide:
1. One persistent conversational Thinker
2. One bounded background Doer
3. A structured shared task ledger
4. Event-based progress reporting
5. User interruption and redirection
6. A verification phase
7. A final structured handoff
The first test cases could involve:
• Multi-file document editing
• Image-batch generation
• Research and citation collection
• Spreadsheet construction
• Code changes followed by tests
• Long-form artifact production
EVALUATION METRICS
USER EXPERIENCE
• Reduction in user uncertainty during long tasks
• User-reported trust and continuity
• Frequency of successful mid-task corrections
• Reduction in task abandonment
• Perceived responsiveness
TASK PERFORMANCE
• Reduced wasted tool actions
• Lower retry rates
• Earlier detection of misunderstanding
• Higher verified completion rate
• Reduced post-task reconstruction
• Time from Doer completion to useful user discussion
SAFETY
• Detection of unsafe or unauthorized actions
• Successful interruption before irreversible effects
• False-positive and false-negative supervision rates
• Memory corruption rate
• Agreement between reported progress and actual events
ECONOMICS
• Additional compute consumed by the Thinker
• Savings from earlier correction
• Cost of continuous versus checkpointed monitoring
• Cost per verified successful task
• Appropriate model routing between Thinker, Doer, and verifier
RESEARCH HYPOTHESIS
This proposal does not claim that the architecture is conscious or that it is the only path to AGI.
Its testable hypothesis is:
Long-horizon AI systems may become more coherent, correctable, and useful when durable governed memory, active metacognitive supervision, and bounded execution remain concurrently available rather than occurring only as alternating phases.
The Knower preserves continuity across time.
The Thinker preserves awareness across action.
The Doer changes the external state.
The missing capability may not be teaching AI to think harder. It may be keeping a supervisory intelligence present while another process works.
REQUEST TO OPENAI
Please consider evaluating a persistent conversational supervisor paired with bounded parallel workers in long-running ChatGPT tasks.
The most immediate product goal would be to let users remain in an active relationship with ChatGPT during execution rather than being placed into a silent waiting state.
The longer-term research question is whether concurrent knowing, supervision, and execution produce better correction, continuity, learning, and control than systems that alternate among those functions.tasks.
The most immediate product goal would be to let users remain in an active relationship with ChatGPT during execution rather than being placed into a silent waiting state.
The longer-term research question is whether concurrent knowing, supervision, and execution produce better correction, continuity, learning, and control than systems that alternate among those functions.