원클릭으로
bdi-agency-model
BDI (Beliefs-Desires-Intentions) agency framework for designing autonomous agents with mental state architectures
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
BDI (Beliefs-Desires-Intentions) agency framework for designing autonomous agents with mental state architectures
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Instruction manual for agents driving Port Daddy multi-agent coordination. Use when an agent will edit a repo, recover work, coordinate with other sessions, inspect FleetBar/Fleet Control Center truth, package skill/docs surfaces, or leave a durable handoff. NOT for generic coding that does not need Port Daddy state.
Contributor manual for agents working ON the Port Daddy codebase itself — the daemon, MCP server, FleetBar / Fleet Control Center, website, CLI surface, distribution mirrors, internal recovery ledger, and the named internal actors (Coxswain / Navigator / Cartographer / Lookout / Quartermaster + Shipwright). Use when editing the port-daddy repo. NOT for agents using Port Daddy on other projects (use port-daddy-agent-skill for that), and NOT distributed to public skill catalogs — this skill is private to the port-daddy repo.
Decide which single operator surface — Scout, FleetBar, or pd-console — owns each capability by its distance-from-work (intake/ambient/deep), and audit that placement for authority spread, unenforceable controls, evidence overflow into FleetBar, and hot/cool bus-subscription mismatches. Use when placing a new capability on one of Agent Harbor's three operator surfaces, reconciling a mockup that duplicates a capability across two surfaces, or auditing an existing operator-surface spec before implementation locks it in. NOT for choosing SDK/CLI/MCP/GUI surfaces for API-consuming developers (developer-surface-strategist), designing the concrete interaction flow within one already-assigned surface (agentic-coding-ux-designer), or the hot-bus/cool-bus transport mechanics themselves (swarm-invocation-designer).
Audit what PRs this session produced. Ask: "What work did I do this session that isn't in a PR yet, or isn't merged?" Forces the agent to account for all code changes before declaring done. Use at any point — especially at session end, after a manager wave, or when asked "what's left?"
After each execution wave completes, inspect the DAG's commitment landscape and premortem risk score. If any surviving nodes carry `commitment_level: TENTATIVE`, or if the premortem `recommendation` is `ACCEPT_WITH_MONITORING` or `ESCALATE_TO_HUMAN`, pause execution and run a structured parley: re-evaluate TENTATIVE nodes against the evidence produced by the just-completed wave, update risk severity where warranted, and either promote nodes to COMMITTED, demote them to EXPLORATORY, or prune them before launching the next wave. Parley is a scheduled operation triggered by wave completion — not an ad-hoc intervention — making wave boundaries the natural formation-break point where plans meet reality.
Build and extend pd-console — Port Daddy's GPU-native macOS operator console (GPUI 0.2.x, Zed's Rust UI). Covers the render-agnostic Block/Pane(Surface) contract, the two-thread reqwest↔smol refresh pipeline, Taffy flexbox layout, uniform_list virtual scroll, focus + keyboard nav, the OKLCH theme and ICS maritime flag badges, GPUI's missing text-input, and the real feature-gated cargo/CI gate. Use when adding panes, visual polish, or debugging GPUI rendering/layout/focus in core/pd-console. NOT for the TypeScript daemon, generic Rust toolchain/borrow-checker help (use rust-with-claude-code), or non-pd GPUI apps with a different theme/architecture.
| license | Apache-2.0 |
| name | bdi-agency-model |
| description | BDI (Beliefs-Desires-Intentions) agency framework for designing autonomous agents with mental state architectures |
| metadata | {"category":"Research & Academic","tags":["bdi","agents","agency","mental-states","architecture"],"io-contract":{"kind":"deliverable","produces":[{"kind":"design-doc","description":"BDI architecture blueprint for autonomous agent systems, including belief/desire/intention separation, commitment-reconsideration strategies, and mental state update cycles","format":"markdown"},{"kind":"critique","description":"Analysis of existing agent/planning systems identifying task-orientation vs. goal-orientation gaps and commitment thrashing problems","format":"markdown"},{"kind":"refactor-plan","description":"Concrete steps to retrofit goal-orientation and rational commitment into resource-bounded decision systems","format":"markdown"},{"kind":"diagram","description":"Mental state architecture diagrams showing belief/desire/intention flows, reconsideration decision trees, and multi-agent coordination patterns","format":"svg"}]}} |
| allowed-tools | Read,Write,Edit,Glob,Grep |
Load this skill when facing:
This skill applies beyond robotics/AI agents—it's relevant for any system that must make decisions over time with partial information, including business process systems, game AI, automated trading, and organizational design.
Beliefs (informational state), Desires (motivational state), and Intentions (deliberative state) aren't philosophical conveniences—they're architectural necessities for resource-bounded agents in dynamic environments.
Why separate? Because conflating them creates impossible computational requirements:
The separation enables local updates and selective reasoning.
The core tension:
The empirical finding (bold vs. cautious agents):
Rational commitment = maintaining intentions until there's sufficient reason to reconsider, where "sufficient" depends on environment dynamics and computational costs.
Task-oriented systems: Execute procedures without maintaining why
Goal-oriented systems: Maintain explicit desired states and plans to achieve them
The gap: Most software is task-oriented. BDI provides the minimal architecture for goal-orientation.
Intentions don't just represent commitments—they actively constrain future reasoning:
This is not bounded rationality or satisficing—it's a rational strategy for resource-bounded agents. The alternative (consider all options always) is computationally intractable.
BDI (philosophy/logic tradition) and Soar (cognitive psychology tradition) independently converged on isomorphic architectures:
| BDI Component | Soar Component | Computational Role |
|---|---|---|
| Beliefs | States | World representation |
| Desires | Subgoals | Motivational targets |
| Intentions | Operators | Chosen actions |
| Plans | Problem spaces | Action sequences |
Implication: These components aren't arbitrary design choices but discovered necessities—like multiple cultures independently inventing the wheel. Any system facing similar constraints (bounded resources, partial information, dynamic environments, real-time action) will need similar structures.
IF environment is highly static THEN bias toward bold commitment (rarely reconsider) IF environment is highly dynamic THEN bias toward cautious reconsideration (frequently reevaluate)
IF computational resources abundant THEN can afford more frequent reconsideration IF computational resources scarce THEN must commit more strongly to amortize planning cost
IF action execution is expensive THEN reconsider before acting IF deliberation is expensive THEN commit and act quickly
IF new information directly contradicts intention's preconditions THEN reconsider immediately IF new information merely opens alternatives THEN reconsider only if significantly better
IF system must act in real-time THEN needs intentions (can't replan from desires every cycle) IF system faces conflicting goals THEN needs desire/intention distinction (desires can conflict, intentions cannot) IF system must coordinate with others THEN needs explicit intentions (for commitment communication) IF system must explain behavior THEN needs all three (explain actions via intentions, intentions via desires, desires via beliefs) IF system must adapt to failures THEN needs goal-oriented representation (to find alternative means)
IF environment is static AND goals are clear AND plans rarely fail THEN task-oriented architecture may suffice IF environment changes OR goals conflict OR plans frequently fail THEN need BDI-style architecture IF multiple agents must coordinate THEN need explicit commitment mechanisms (load multi-agent reference) IF system must learn from experience THEN need BDI + learning extensions (load learning reference)
| Reference File | Load When... | Key Content |
|---|---|---|
why-beliefs-desires-intentions-exist.md | Justifying architectural decisions; explaining why three components are necessary | Detailed computational argument for BDI separation; what each component solves; costs of conflation |
rational-commitment-and-reconsideration.md | Designing reconsideration strategies; debugging thrashing or stubbornness | Kinny-Georgeff experiments; bold vs. cautious agents; meta-level control; empirical results |
task-vs-goal-orientation.md | Comparing architecture approaches; explaining need for goal representation | Deep dive on task/goal distinction; recovery capabilities; opportunistic replanning; explainability |
soar-bdi-convergent-evolution.md | Validating design choices; comparing with cognitive architectures | Soar-BDI mapping; convergent evolution argument; universal principles; cross-tradition insights |
multi-agent-commitment-and-coordination.md | Designing multi-agent systems; coordination protocols | Joint intentions; social commitments; team reasoning; coordination mechanisms; distributed BDI |
learning-the-missing-piece.md | Adding adaptation; integrating ML with planning | BDI limitations; learning integration strategies; experience-based improvement; open challenges |
references/why-beliefs-desires-intentions-exist.md — Explains why B/D/I separation is computationally necessary, not philosophical. Read when designing agent architecture or justifying mental state separation.references/rational-commitment-and-reconsideration.md — Kinny-Georgeff experiment showing optimal replan frequency in dynamic environments. Read when tuning commitment vs. reconsideration trade-offs.references/task-vs-goal-orientation.md — Contrasts task-oriented (conventional software) vs. goal-oriented (BDI) systems. Read when debugging failure recovery or replanning gaps.references/multi-agent-commitment-and-coordination.md — Extends BDI to multi-agent scenarios; addresses joint commitments. Read when coordinating multiple agents or forming team plans.references/soar-bdi-convergent-evolution.md — Shows Soar and BDI independently converged on same architecture. Read when validating BDI design or integrating with cognitive architectures.references/learning-the-missing-piece.md — Identifies learning/adaptation gap in basic BDI model. Read when adding adaptive behavior or long-term improvement to agents.diagrams/01_flowchart_bdi_agent_decision_cycle_and_r.md — Mermaid flowchart of perception→belief→desire→intention→execution cycle. Read when implementing agent control loop or explaining decision flow.diagrams/02_stateDiagram-v2_intention_lifecycle:_commitmen.md — State machine for intention lifecycle and commitment-reconsideration transitions. Read when modeling when agents should abandon or persist with plans.diagrams/03_quadrantChart_environment_dynamics_vs._compu.md — 2×2 matrix mapping environment dynamics and resource scarcity to reconsideration strategies. Read when selecting commitment strategy for specific operational context.Symptom: System constantly reconsiders all options, thrashes between plans, never completes actions Root cause: Treating every belief update as requiring complete replanning (classical decision theory mistake) BDI insight: Rational commitment means maintaining intentions despite minor belief changes
Symptom: System continues executing plan after goal achieved or becomes impossible Root cause: Task-oriented architecture without goal representation BDI insight: Maintain explicit relationship between intentions, plans, and desires to enable goal-aware execution
Symptom: System tries to pursue conflicting goals simultaneously, resources spread too thin Root cause: Not distinguishing between "would like to achieve" and "committed to pursuing" BDI insight: Desires can conflict; intentions cannot (must resolve conflicts during deliberation)
Symptom: System abandons plans at first difficulty; erratic, unpredictable behavior Root cause: Treating intentions as weak preferences rather than commitments BDI insight: Intentions constrain future reasoning—they're not just goals but committed goals
Symptom: System fails when environment changes; no recovery from failures Root cause: Conventional software approach (plan = fixed procedure) BDI insight: Plans must be monitored against goals; reconsideration needed when environment dynamics high
Symptom: Fixed reconsideration strategy fails across different environment dynamics Root cause: Not adapting commitment strategy to environment characteristics BDI insight: Need meta-level reasoning about when to reconsider (the central open problem)
Symptom: Coordination failures; agents undermine each other's plans Root cause: Using individual BDI without social commitment mechanisms BDI insight: Multi-agent requires joint intentions and commitment communication protocols
Key diagnostic question: "Why can't you just merge desires and intentions?"