# PMFlow AI Agent OS Runtime ## 1. Purpose This document is the target architecture for PMFlow AI after removing the old `/ask -> answer` center. PMFlow AI is not a smarter classifier, a fixed answer template, or a single chat bubble. The target is an Agent OS behind a Codex-style thread product: the user sees one continuous thread, each user message creates an internal durable agent run, the runtime binds the workspace, plans the next step, executes read/probe/agent tools, stores observations, verifies the result, recovers when needed, learns from the cycle, and only then composes the customer answer from verified state. The current implementation has moved past the first Agent OS shell. The user-visible truth source is still `pmflow_ai_threads / pmflow_ai_messages`; `pmflow_agent_runs` is the execution truth source for each assistant turn; `QARecord` remains transcript/history only. The product runtime is now mission-first: each assistant turn creates an `OperatingMission`, assigns specialist agents, compiles a council-reviewed operating decision, projects product objects, prepares execution/confirmation packets, and writes learning/next-cycle signals before customer projection. ## 2. Canonical Chain ```text PMFlow AI -> Thread Workspace -> User Message -> Agent Run Workspace -> Operating Mission -> Stage / Deliverable / Action Ladder -> Mission Workspace -> Specialist Agent Registry -> Parallel / Sequential Specialist Work Products -> Evidence + Artifact Ledger -> Agent Council / Critic -> Product Object Projection -> Action Ladder + Human Review Gate -> Execution Bridge Preparation -> Outcome Observation -> Learning Ledger + Next Cycle Trigger -> Customer Payload ``` Compatibility endpoints may still return chat-shaped payloads, but they must be projections of the PMFlow AI Thread + Agent OS Run model. ## 3. Non-Goals - Do not build another prompt router or answer classifier. - Do not let `QARecord`, `answer_type`, `answer_shape`, `route_plan`, `source_strategy`, `allowed_executors`, `task_type` or frontend UI state decide the run. - Do not restore keyword routing, regex routing, `looks_like_*` helpers, scene enums, or hard-coded business stage lists. - Do not expose `project_object_required_for_world_state`, `world_state`, `packet`, `trace`, `prompt`, `function`, `route_plan`, table names, raw field names, model/provider details, or English reasoning to customers. - Do not show fixed five-step progress. Process display must come from real persisted Agent OS steps. - Do not expose `Run`, raw run status, step ids, target refs, verification ids, `passed`, `final_answer`, or other execution identifiers in the default PMFlow AI user interface. - Do not keep the right-bottom chat bubble as the product surface. The product surface is `/space/pmflow-ai`. ## 4. Core Runtime Objects ### PMFlow AI Thread `pmflow_ai_threads` is the user-visible PMFlow AI truth source. One thread contains a continuous conversation and can span many agent runs. The left sidebar lists threads, not runs. ### PMFlow AI Message `pmflow_ai_messages` stores user and assistant messages in a thread. Assistant messages carry a customer-safe projection: - final answer text - collapsible work log - inline artifacts - inline action candidates - inline confirmation requests It does not expose raw step ids, verification records, provider traces or internal object-gap labels. ### Agent Run `pmflow_agent_runs` is the execution truth source for one assistant turn. It stores tenant/user/thread/session, goal, status, final answer, runtime policy, source endpoint and customer-safe payload. Runs are not the primary user-navigation object. ### Operating Mission `PMFlowAIOperatingMission` upgrades the raw user message from a question into a business operating task. It includes `mission_goal`, `stage`, `desired_business_outcome`, `target_objects`, `required_agents`, `deliverable_type`, `action_ladder_level`, `success_criteria`, `blocked_boundaries` and `next_cycle_policy`. ### Specialist Agent Registry `PMFlowAIOperatingAgentRegistry` is the canonical specialist contract surface. Current registered roles are: - `idea_incubation_agent` - `market_research_agent` - `competitor_agent` - `product_strategy_agent` - `mvp_scope_agent` - `tech_architect_agent` - `pm_breakdown_agent` - `qa_risk_agent` - `growth_agent` - `monetization_agent` - `learning_agent` Each contract declares input contract, output artifact, allowed tools, write permissions, autonomy limit, critic checks and customer-safe projection. Selection comes from OperatingMission and project/object scope, not keyword routing. ### Product Object Projection `PMFlowAIProductObjectProjection` turns specialist outputs into PMFlow business objects before answer projection. Supported object families are `IdeaSeed`, `ResearchNote`, `OpportunityBrief`, `ProductHypothesis`, `MVPOption`, `RequirementDraft`, `ChangeSetDraft`, `TaskDraft`, `ExecutionPackage`, `QAPlan`, `ReleaseSignal`, `GrowthExperiment` and `RevenueSignal`. These are draft/customer-safe projections until explicit confirmation moves them into the relevant product chain. ### Agent Step `pmflow_agent_steps` records every planned/executed step: - operating mission / workspace snapshot - planner actions - read/probe tools selected from `AGENT_TOOL_CONTRACTS` - external public search - project operating state reads - specialist work product generation - council review and autonomy gate - product object / execution preparation / learning projection - critic checks - answer runtime Steps are not UI decorations. They are the persisted execution trace customers can inspect in a product-safe form. ### Observation `pmflow_agent_observations` stores read/probe results as facts, candidates, gaps, and context observations. Tools return observations and artifacts, not final answers. ### Artifact `pmflow_agent_artifacts` stores product object projections, specialist work products, council summaries, prepared action packets, confirmation requests, research notes and other durable run outputs. ### Verification `pmflow_agent_verifications` stores step verification, blocked reasons, recovery decisions, role checks and customer-answer safety checks. ### Memory `pmflow_agent_memories` stores learning and next-cycle signals that can be consumed by future runs. QA transcript is historical conversation; Agent memory is the operational state layer. ## 5. Implemented Packet Landing ### Packet 1: Mission Runtime Implemented: - `backend/app/schemas/pmflow_ai_operating_runtime.py::PMFlowAIOperatingMission` now carries `stage`, `desired_business_outcome`, `target_objects`, `deliverable_type`, `action_ladder_level`, `blocked_boundaries` and `next_cycle_policy`. - `backend/app/services/pmflow_ai_operating_runtime/mission_service.py` uses `PROMPT_PMFLOW_AI_OPERATING_MISSION` through Prompt Runtime when available, with a conservative mission-first fallback. - Unbound open opportunities default to research/opportunity missions and project-bound turns default to project operating missions. Both produce specialist assignments and product-object-ready success criteria instead of a plain answer target. ### Packet 2: Specialist Agent Registry Implemented: - `backend/app/services/pmflow_ai_operating_runtime/agent_registry.py` replaces the old six-role project-only set with 11 specialist contracts: idea, market research, competitor, product strategy, MVP scope, tech architect, PM breakdown, QA/risk, growth, monetization and learning. - `backend/app/services/pmflow_ai_operating_runtime/specialist_agents.py` produces role-specific work products with claims, recommendations, prepared actions, blocked actions, evidence refs and verification. - Market research is now a recovery-capable specialist, not a normalizer wrapper. External search observations from the inner evidence loop are promoted into `external_research_evidence` on the operating world state; the `market_research_agent` consumes source candidates, usable claims and research gaps to decide whether a ResearchNote is ready or whether the next action is read-only research recovery. - Legacy `pmflow_agent_runtime/specialists.py` remains only for the old compatibility loop and tests; it is not the `/space/pmflow-ai` product main controller. ### Packet 3: Orchestrator + Council Implemented: - `backend/app/services/pmflow_ai_operating_runtime/run_service.py` is now the default delegate from `PMFlowAgentRuntimeService`. - `backend/app/services/pmflow_ai_operating_runtime/council.py` reviews role outputs, detects blocked role products, risk vetoes, priority competition and evidence boundaries, then compiles one priority order. - `PROMPT_PMFLOW_AI_OPERATING_COUNCIL` is registered for prompt operations; deterministic council logic remains the safe baseline and no keyword/scene route is introduced. ### Packet 4: Product Object Projection Implemented: - `PMFlowAIProductObjectProjection` projects specialist artifacts into `OpportunityBrief`, `ResearchNote`, `MVPOption`, `TaskDraft`, `GrowthExperiment`, `RevenueSignal` and related object families. - `operating_plan.product_object_projections`, `command_payload.product_object_projections`, `operating_run_packet.product_object_projections` and `agent_os_product_object_projections` are all sanitized customer-safe payload fields. - Product objects are draft/proposed outputs until user confirmation; they do not write Project Memory, commit ChangeSet, create tasks or start execution. - Open market/opportunity turns must not jump to `OpportunityBrief` from shallow evidence. If `ResearchNote.evidence_state.ready_for_opportunity_brief=false`, the projection remains a draft `ResearchNote` with source plan, gaps and boundaries; the prepared action family is `research_recovery`, not a project write or execution handoff. ### Packet 5: Execution Bridge Deepening Implemented: - `ExecutionPreparationService` now emits `execution_bridge_handoff_preparation.v1` inside `PMFlowAIExecutionPreparation.handoff_package`. - The handoff package includes `execution_capability_graph`, `prompt_package_contract` and `result_writeback_contract(protocol_version=execution_result_protocol_v1)`. - Execution preparations remain `prepared_waiting_confirmation` until the user clicks a confirmation action. Confirmed handoffs are executed through `POST /space/pmflow-ai/threads/{thread_id}/confirmations/{confirmation_id}/execute`, which resolves the persisted action contract server-side and then calls PMFlow OS `create_execution_handoff`; it does not trust frontend-built prompts or payload-only writes. - Inline confirmation requests are action contracts, not decorative warning cards. Customer-safe confirmations now carry `action_label / action_type / action_payload / can_execute`; `continue_research` starts another read-only PMFlow AI turn with the compiled source plan and re-enters observe/specialist/council, `save_candidate` writes only to the pre-project saved idea chain, and `start_execution_handoff` creates a PMFlow OS prompt package for a formal task. - Execution Bridge result writeback remains outside the backend command runner. External runtimes pull packages and report results through signed PMFlow OS runtime endpoints (`/pmflow-os/runtime/execution-packages`, `/pmflow-os/runtime/execution-results`); the next PMFlow AI project re-observation reads `execution_progress` from the PMFlow OS projection instead of relying on chat transcript. ### Packet 6: Learning + Next Cycle Implemented: - `OperatingCycleService` consumes previous `operating_learning_ledger` capsules and writes outcome observations for pending confirmations, experiments, execution preparations and user preference signals. - Learning items now capture `operating_partner_not_qa`, `single_priority_order`, `product_object_first`, source-effectiveness policy and risk threshold. - `next_cycle_triggers` include user turn, signal, execution result, daily review, weekly strategy review and task update when confirmation state changes. ## 6. Legacy 5-Step Foundation ### Step 1: Agent OS Truth Source Implemented: - Durable tables in `backend/app/models/pmflow_agent_runtime.py` and migration `backend/alembic/versions/20260513_add_pmflow_agent_runtime.py`. - Durable PMFlow AI thread/message tables in `backend/alembic/versions/20260513_add_pmflow_ai_threads.py`. - `backend/app/services/pmflow_agent_runtime/service.py::PMFlowAgentRuntimeService` creates the durable run first, delegates product execution to `PMFlowAIOperatingRunService`, then persists the real operating/process steps, observations, artifacts, verifications and memories. - `GET /space/pmflow-ai/threads`, `POST /space/pmflow-ai/threads`, `GET /space/pmflow-ai/threads/{thread_id}` and `POST /space/pmflow-ai/threads/{thread_id}/messages` expose the user-facing PMFlow AI product surface. - `/space/pmflow-ai/runs*` remains compatibility/debug surface only. Product UI must not use runs as the primary conversation list. - `POST /space/ai-concierge/ask` is compatibility only and enters the same `PMFlowAgentRuntimeService.run_space_turn()` path. - Thread payloads return `thread_id / messages / assistant_message`; each assistant message contains answer, work log, inline artifacts, action candidates and confirmations. Required behavior: - `你是谁` creates a run with capability observation and does not read project world state. - `现在有哪些项目` creates a space observation. - `这个项目怎么推进` reads project world state only when a strong project anchor exists. - `QARecord` is transcript/history, not the thread or run truth source. ### Step 2: Evidence Observe-Plan-Act-Critic Loop Implemented through `backend/app/services/pmflow_ai_agent_runtime/agent_run_service.py`. This loop is now an evidence/answer adapter inside the operating runtime, not the Space PMFlow AI mission owner. The loop runs: ```text understand_goal -> GoalFrame -> workspace snapshot -> LLM step planner -> selected read/probe tool -> observation ledger -> universal evidence normalizer -> claim/boundary/action ledger -> state critic -> recover/continue/stop -> answer runtime ``` Rules: - The planner chooses from typed `AGENT_TOOL_CONTRACTS`; it must not use keyword routers, fixed executor enums or old answer contracts. - The state critic treats the GoalFrame as the acceptance test. A step can pass only if normalized claims/boundaries/gaps move the run toward that goal. - If a user asks for market/current public information, the planner can select `external_search`; the evidence normalizer must turn public material into usable claims or source-quality boundaries before the answer runtime can use it. - External research recovery is part of the main loop, not a UI retry. When source detail fetch fails, source quality is blocked, or no claim enters the ledger, the runtime must first read untried ranked sources from the same observation; only when no candidate remains may it re-search from the GoalFrame evidence gaps. A failed first URL must not abort the whole source batch. - The pre-research loop must close before downstream objects advance: `search -> read -> normalize -> critic -> recover -> re-read -> re-normalize -> ResearchNote`. LLM normalizer output is not allowed to suppress deterministic source extraction; if the LLM only returns noisy/gap diagnostics but the customer-safe source text contains gated facts, the deterministic extraction wins and the diagnostics are retained as gaps. Chinese numeric/time evidence such as `2025年`, `%`, `亿/万元` must count as substantive signal after quality gates. - Source quality is enforced at fragment level, not page level. A fetched page may contain navigation, ads, login copy or other shell text, but only clean fragments with substantive business signals may enter the Claim Ledger. Page shells, short title-only fragments, HTML entity noise, link-dense text, markdown/table composites and generic source-candidate statements remain blocked from claims. A year alone does not qualify as a ResearchNote claim; it must be paired with adoption, budget, attendance, revenue, growth, risk, forecast or another customer-useful signal. Candidate sources can remain visible as research candidates, but final answers and ResearchNote readiness consume only gated claims. - Search provider synthesized answer text is not source evidence. If a provider returns multiple URL candidates and one generated summary, the generated summary must not be copied into every source snippet. `external_public_evidence` observations are source candidates only; they can create source plans and boundaries, but cannot create ResearchNote claims until `inspect_source_detail` reads source text and the normalizer extracts clean source-bound facts. - Critic veto is a hard control gate. When the critic says `ready_to_answer=false` and a retry/read would change state, the answer runtime must not override it because there are partial directional claims. The runtime must either continue recovery with the next read/research action or return a blocked/recover customer answer built from Boundary/Attempt Ledger, not a market conclusion. - Interpretation branches are evidence hypotheses, not keyword routes. Normalized external claims may carry `interpretation_branch_id` when their fragment overlaps the GoalFrame branch profile; the critic uses that to answer a supported branch with explicit boundaries instead of repeating the same failed query or pretending that unrelated branch evidence answers the whole goal. - Branch coverage gaps are evidence boundaries, not automatic vetoes, for `directional_answer / partial_answer` goals. If a reasonable interpretation branch has gated claims, PMFlow AI should answer that branch with a clear assumption and keep the uncovered branch as a remaining gap. Strict/official/fail-closed policies still block when required. - `ResearchNote.ready_for_opportunity_brief=false` only blocks downstream `OpportunityBrief / CompetitorMap / Execution` preparation. It must not erase useful gated claims. The final answer may give a bounded initial read from those claims while saying why it cannot yet upgrade to an opportunity brief or execution action. - Process display must expose true total count separately from the visible preview. The collapsed work log can show `12/真实总数`; expanding must use backend-provided customer-safe steps instead of frontend-fixed step templates. - Specialist agents may not advance later-stage object shells when the previous stage is not ready. For open market/opportunity research, `ResearchNote` must reach the minimum source/claim threshold before `CompetitorMap`, `OpportunityBrief`, execution handoff or growth/revenue objects become prepared actions. - Project operating state is read only when a strong project anchor exists. Current checkpoint: - The front research loop is contractually closed as `search -> read source detail -> normalize -> critic -> recover -> re-read or re-search -> re-normalize -> ResearchNote threshold`. - Single external query plans remain bounded (`result_limit <= 5`), but the agent run budget allows multiple read/recovery turns. More evidence comes from the loop, not from raising one provider call to an unbounded result count. - If the LLM normalizer returns an empty response, the deterministic fallback can still extract customer-safe, goal-relevant claims from already-read source text. It does not promote raw source candidates, navigation pages, emails, phone numbers or generic source labels into the claim ledger. - Source and claim quality are now separate gates. `agent_evidence_quality.py` blocks page shell, navigation, ad/contact fragments, HTML entities, link-dense text, source-candidate statements, generic source wrappers and raw page fragments before they can become ResearchNote evidence. The normalizer, critic, answer runtime and operating-world-state merge must all use this shared gate; no layer may rebuild its own looser claim filter. - Critic veto is enforced through gated claims rather than raw claim count. If every observed claim is invalid, the runtime must recover with another read/search when state can change, or stop as a blocked evidence state. It must not answer from a non-empty but invalid `claim_ledger`. - Final answer projection must consume only gated terminal claims/ResearchNote facts. Raw source fragments, source candidates and deliverable section text that fails the shared claim gate cannot be merged back into the operating answer or customer canvas. - Customer process display returns both a visible slice and the full customer-safe process list: `work_log`, `work_log_full`, and `work_log_meta(total_step_count, visible_step_count, hidden_step_count, truncated)`. The frontend displays `12/19` style counts and expands to all customer-safe steps instead of silently hiding later recovery/re-read steps. - Recovery is no longer optional when the critic says another read would change state. If no more untried URLs remain, the runtime builds a recovery search from the user goal, GoalFrame evidence requirements and critic gaps; if tool budget is exhausted, the stop reason is explicit `research_recovery_budget_exhausted`. - The specialist registry no longer truncates open research to a fixed front-stage whitelist. Requested specialists remain assigned, but downstream roles block their own prepared actions until the ResearchNote threshold is met. - Customer thread payloads preserve the final operating answer and machine action contracts (`action_type`, `action_payload`) separately from display text, so the UI does not replace the answer with a safety fallback or drop executable confirmation metadata. Still intentionally not started in this checkpoint: - Confirmed execution handoff result polling/writeback beyond existing PMFlow OS runtime endpoints. - Autonomous project writes, ChangeSet commits, task creation or Project Memory updates from open research. - Growth/revenue/QA downstream object preparation before the ResearchNote threshold is satisfied. - The run has iteration, tool-call and repeated-action budgets to prevent dead loops. ### Step 3: Runtime Tools / Agent Steps Implemented as typed agent tools in `backend/app/services/pmflow_ai_agent_runtime/agent_tool_registry.py`. Current product tools include: - `inspect_space_collections` - `inspect_project_operating_state` - `resolve_customer_object` - `inspect_object_detail` - `inspect_saved_ideas` - `inspect_pending_confirmations` - `external_search` - `inspect_pmflow_capability_boundary` The old fixed durable loop in `pmflow_agent_runtime/loop.py` is no longer the `/space/pmflow-ai` main controller. It remains a legacy compatibility asset until all old tests/debug consumers are removed. `PMFlowAIOperatingRunService` is now the mission-first product controller and may override the evidence adapter’s plain answer with council-reviewed operating output. Rules: - `你是谁` does not enter specialist/council/autonomy. - `帮我看看市场上有没有什么新的好项目` must not be answered from PMFlow capability or space project list alone; it needs external/public observations and opportunity candidates or an explicit evidence boundary. - `这个项目怎么推进` enters the project operating read path when a project is bound. - Specialist/opportunity outputs enter observations, artifacts and deliverables, not direct answer overrides. - `project_object_required_for_world_state` is an internal verification detail only and must never appear in the customer answer. ### Step 4: Terminal Answer State + Natural Answer Runtime Implemented in `backend/app/services/pmflow_ai_agent_runtime/agent_answer_runtime.py`. The answer layer consumes the final workspace, latest observation and critic result. It builds: - terminal claims - customer-safe boundaries - attempts - remaining gaps - next possible actions - deliverable packet Then `PROMPT_PMFLOW_AI_AGENT_ANSWER_COMPOSER` writes the natural answer. If the LLM answer leaks internal terms or misses the lead claim/boundary, the generic repair path rebuilds the answer from terminal state. Customer-visible forbidden terms include: ```text project_object_required_for_world_state mission world_state packet trace prompt function route_plan 当前对象（空对象） Claim Ledger Boundary Ledger TurnState 英文内部推理 固定“判断依据/证据边界/下一步”三段式 ``` The critic repairs or blocks answers that leak internal runtime terms, echo process plans as final answers, return empty text, or fall back to fixed templates. ### Step 5: PMFlow AI Workspace Implemented: - The right-bottom chat bubble is removed from `frontend/src/features/personal-space/PersonalSpacePage.tsx`. - The first Space sidebar item is `PMFlow AI` in `frontend/src/features/personal-space/components/SpaceChrome.tsx`. - Main route: `/space/pmflow-ai`. - Legacy route `/space/agent-command-center` redirects to `/space/pmflow-ai`. - `frontend/src/features/personal-space/components/PMFlowAIWorkspace.tsx` is the Codex-style workspace: - left thread list - middle continuous transcript - bottom composer - per-assistant-message collapsible work log - inline artifacts, action candidates and confirmation requests - new thread, continue current thread, refresh - no local answer fallback; failed sends clear the composer and show an explicit non-committed error instead of replaying the submitted text as if it entered the durable chain - Frontend API wrappers live in `frontend/src/api/aiSteward.ts`: - `createPMFlowAIThread` - `sendPMFlowAIThreadMessage` - `streamPMFlowAIThreadMessage` - `listPMFlowAIThreads` - `getPMFlowAIThread` Frontend must only display backend customer-safe `work_log / artifacts / actions / confirmations`. It must not render raw `agent_os_steps`, `agent_os_verifications`, step ids, target refs or English status labels in the default user experience. ## 7. Current API Contract ### `POST /space/pmflow-ai/threads` Creates a PMFlow AI thread and sends the first user message. The backend creates an internal Agent Run for that assistant turn. Input shape follows the existing Space ask body: - `question` - `surface_context` - `asked_via` - `thinking_mode` - `action_mode` Return payload includes: - `thread_id` - `title` - `messages[]` - `assistant_message` Assistant messages include: - `content` - `run_id` - `work_log[]` with customer-safe Chinese labels/summaries - `artifacts[]` - `actions[]` - `confirmations[]` ### `POST /space/pmflow-ai/threads/{thread_id}/messages` Continues the same PMFlow AI thread. The next user message creates a new internal Agent Run attached to the same thread. It must append to the transcript, not create a new user-visible run row. ### `POST /space/pmflow-ai/threads/stream` Creates a PMFlow AI thread through the same durable Agent OS path, then streams customer-safe progress and the final thread projection. The stream endpoint must pass `event_sink` through `PMFlowAgentRuntimeService -> PMFlowAIOperatingRunService -> PMFlowAIAgentRunService`; a signature mismatch or swallowed event sink is a main-chain failure, because it prevents real runtime steps from reaching both the UI and audit trail. ### `POST /space/pmflow-ai/threads/{thread_id}/messages/stream` Continues the same PMFlow AI thread with SSE. Allowed events are `run.started`, `step.started`, `step.completed`, `answer.started`, `answer.delta`, `answer.completed`, `thread.completed` and `error`. `thread.completed` is the only success marker for committing the visible thread detail. If the stream errors before completion, the frontend must not persist a fake message or restore the composer as though the send succeeded. ### `GET /space/pmflow-ai/threads` Lists PMFlow AI threads for the current tenant/user. ### `GET /space/pmflow-ai/threads/{thread_id}` Returns one thread and its continuous message transcript. ### `/space/pmflow-ai/runs*` Compatibility/debug surface for internal Agent Run inspection. The product UI must not use it for primary conversation navigation. ### `POST /space/ai-concierge/ask` Compatibility endpoint. It must call the same Agent OS runtime and return the same customer-safe Agent OS payload projection. It must not restore old `/ask` route planning as the main control path. ## 8. Acceptance Cases 1. `你是谁` - Answer identity, ability and boundary. - Do not read project world state. - Do not run specialist/council/autonomy. - Do not leak internal terms. 2. `现在有哪些项目` - Read current Space state. - Return real visible projects or an empty state. - Do not require a project object. - Do not run council. 3. `这个项目怎么推进` - With a strong object anchor, read project world state. - Run project operating specialists/council/autonomy as needed. - Return judgement, priority actions, confirmation boundary and evidence boundary naturally. 4. `帮我全面推进当前空间` - Organize a multi-agent run. - Select cross-project candidates from visible/authorized state. - Produce a run plan and continue until waiting confirmation, blocked boundary or completion. 5. Tool failure - Persist the failing step and verification finding. - Generate a recovery step when retry can change state. - Do not turn raw errors into customer answers. 6. User confirmation - Execute only after confirmation. - Re-observe and verify after action. - Update run status and memories. 7. Replay `qa_records.id=1713` - Final answer must be the identity answer. - Project world-state gap must not override the main answer. ## 9. Files Backend: - `backend/app/models/pmflow_agent_runtime.py` - `backend/app/schemas/pmflow_agent_runtime.py` - `backend/app/schemas/pmflow_ai_operating_runtime.py` - `backend/app/services/pmflow_agent_runtime/service.py` - `backend/app/services/pmflow_ai_operating_runtime/run_service.py` - `backend/app/services/pmflow_ai_operating_runtime/mission_service.py` - `backend/app/services/pmflow_ai_operating_runtime/agent_registry.py` - `backend/app/services/pmflow_ai_operating_runtime/specialist_agents.py` - `backend/app/services/pmflow_ai_operating_runtime/council.py` - `backend/app/services/pmflow_ai_operating_runtime/autonomy.py` - `backend/app/services/pmflow_ai_operating_runtime/cycle.py` - `backend/app/services/pmflow_agent_runtime/loop.py` - `backend/app/services/pmflow_agent_runtime/answer.py` - `backend/app/services/pmflow_agent_runtime/specialists.py` - `backend/app/api/space_api/__init__.py` - `backend/app/api/rag_ask_contract.py` - `backend/tests/test_pmflow_ai_agent_runtime_step1.py` Frontend: - `frontend/src/api/aiSteward.ts` - `frontend/src/features/personal-space/components/PMFlowAIWorkspace.tsx` - `frontend/src/features/personal-space/components/SpaceChrome.tsx` - `frontend/src/features/personal-space/PersonalSpacePage.tsx` - `frontend/src/router/index.tsx` - `frontend/src/features/personal-space/PersonalSpacePage.test.tsx` Legacy/demoted: - `backend/app/services/pmflow_ai_agent_runtime/agent_run_service.py::PMFlowAIAgentRunService` is now the evidence/answer adapter inside the operating runtime, not the Space user-side mission owner. - `backend/app/services/pmflow_agent_runtime/loop.py`、`answer.py`、`specialists.py` are legacy compatibility assets and must not regain product main-control status. - `frontend/src/features/personal-space/components/SpaceAIConcierge.tsx` has been deleted from the Space product surface; shared surface-context construction now lives in `frontend/src/features/personal-space/components/spaceSurfaceContext.ts`. - `/space/ai-concierge/ask` is compatibility, not the terminal product path. ## 10. Next Deepening Work The Packet 1-6 landing establishes the operating-agent architecture. The current hardening status is: - Open market/research missions now stay on the front-stage operating chain until ResearchNote evidence is usable: Idea Incubation, Market Research and Product Strategy. Growth, monetization, learning writeback and execution handoff must not appear as executable customer cards before the research threshold is met. - Inner Agent OS observations are promoted from `agent_os_observations`, `agent_run_packet.observations` and `agent_workspace.observations` into the Operating World State before specialists/council run. Operating answers must not report `0 sources / 0 claims` when the delegated read loop has actually observed sources. - Candidate-source claims no longer count as substantive claims for recovery blocking. If the critic says retry can change state, the run must re-observe by reading untried sources or issuing a recovery search instead of stopping at `no_state_delta_recovery_blocked`. - Recovery search is only allowed inside the external research read chain. A generic space/project read with insufficient state must return to the normal planner, not be forced into public search. - Recovery search must diversify from the GoalFrame interpretation branches and critic gaps, while excluding attempted source URLs. An off-branch claim cannot block recovery for a higher-priority uncovered branch. - If the critic says the state is not ready and another read/retry can change the state, terminal state is `waiting_for_evidence`. Product object projection must not consume claim ledger rows from that terminal state. - ResearchNote projection must only use gated claims from an answerable or partially-answerable terminal state. Page shells, candidate-source fragments and off-branch claims are not enough to become a market judgement. - Source relevance and claim relevance are hard gates before ResearchNote readiness. A fetched source can mention the right broad topic and still be rejected if the extracted fragment does not align with GoalFrame evidence requirements or if it is only a raw page/event/investment fragment. - Critic readiness must check the ResearchNote threshold, not only claim count. External research needs independent source support and enough evidence-requirement coverage before `ready_to_answer=true`; otherwise the only valid result is recover or blocked. - Answer quality is fail-closed for external research. If the final draft still contains raw source noise, repeated page fragments, unsupported external claims, internal terms or other severe findings after revision/repair, the runtime rebuilds a blocked terminal answer instead of returning the bad draft. - Packet AZ locks the customer-visible truth source for external research: the gated ResearchNote or blocked recovery deliverable is the only text source for `answer`, `reply_text`, `answer_canvas.direct_answer`, stored message payloads and frontend rendering. API projection may sanitize protected implementation terms, but it must not replace an Agent Runtime answer with a separate canvas/action fallback. If the state is blocked, the blocked recovery deliverable is shown as the answer; if it is answerable, only gated ResearchNote facts may feed the answer. - Operating answer text must be the same text used by `answer_canvas.direct_answer`, so the UI cannot show the old inner answer while the message body shows the operating answer. - Confirmation requests must preserve `action_type / action_label / action_payload / can_execute_after_confirmation`, otherwise the frontend shows non-executable process cards. To approach Codex-level behavior in the project-operating domain, deepen these modules in order rather than rebuilding the architecture again: - Let specialist agents use richer typed tools and controlled parallelism, without restoring keyword or enum branching. - Expand tool coverage for project memory, task graph, change review, release/growth, capacity and external evidence as typed observations/work products. - Expand project-bound execution handoff coverage with formal task/repo fixtures and runtime credential smoke tests. - Add golden cases for confirmed research recovery re-observe/re-council, saved idea promotion and execution result writeback learning. - Add UI affordances for completed confirmation actions and blocked execution-preparation gaps. - Persist learning memory beyond QA session capsules when run volume requires dedicated memory projection tables.