skills/agentspeak-l-bdi-agents-speak-out-in-a-logical-computable/SKILL.md
Design AgentSpeak(L)-style BDI agents with context-guarded plans, selection functions, and intention stacks. Use for interruptible autonomy, agent policy, and multi-agent orchestration in dynamic environments. NOT for simple rule engines, static planners, or centralized workflows.
npx skillsauth add curiositech/windags-skills agentspeak-l-bdi-agents-speak-out-in-a-logical-computableInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill when the hard part is not writing another workflow, but deciding how an autonomous agent should react, commit, suspend work, and explain its choices under changing conditions.
Beliefs model the current world, desires define candidate outcomes, and intentions are the specific committed plan stacks currently consuming execution budget. If those collapse into one blob, the agent stops being interpretable.
AgentSpeak plans are not generic procedures. They are event-triggered recipes with context guards, so the same goal can invoke different behaviors depending on what the agent currently believes.
The event selector, option selector, and intention selector are where urgency, fairness, and risk tolerance belong. Plans should encode know-how; selection functions should encode strategy.
Intentions are partially executed stacks that can be interleaved, suspended, and resumed. That is what allows responsive agents to handle interrupts without turning every long task into a restart.
The practical lesson from AgentSpeak(L) is to start from an operational agent cycle and formalize what it actually does. Do not write an elegant abstract theory that has to be approximated into runtime behavior later.
flowchart TD
A[Need autonomous behavior design] --> B{Persistent commitments required?}
B -->|No| C[Use rules, state machines, or a plain workflow]
B -->|Yes| D{Environment interrupts active work?}
D -->|No| E[Classical planner may suffice]
D -->|Yes| F{Need policy separate from plans?}
F -->|No| G[Custom agent loop, but expect coupling]
F -->|Yes| H[Use AgentSpeak-style BDI]
H --> I{Current problem}
I -->|Wrong task chosen| J[Revisit SI or SE]
I -->|Wrong plan chosen| K[Revisit SO or context guards]
I -->|Failure kills execution| L[Add failure events and recovery plans]
I -->|Hard to audit| M[Expose intention stack and selection traces]
Cue: the design says the agent "has a goal" but cannot show whether it has actually committed resources to it.
Fix: represent candidate goals separately from currently active intention stacks.
Cue: every plan body contains priority, fairness, or urgency branching.
Fix: move those choices into event, option, or intention selection functions.
Cue: plans are so long that any interrupt forces the whole sequence to restart mentally.
Fix: split long behaviors into shorter plans with explicit subgoal boundaries.
Cue: a failed subgoal aborts the whole agent or silently disappears.
Fix: model failure as an event that can trigger recovery, retry, or abandonment plans.
Cue: plans match on vague world assumptions that are never tied to real beliefs or observations.
Fix: make belief update paths explicit and keep guards queryable against current belief state.
A coding agent is working through a long refactor when a high-severity production alert arrives. Model the refactor as one intention stack and the alert as a new event. Let selection functions preempt the refactor, then resume it later without losing state.
Several mobile agents share a belief base about aisle congestion and inventory state. Their domain knowledge stays in plans, while selection functions encode which urgent pick jobs outrank replenishment work under congestion.
references/bdi-architecture-for-agent-orchestration.md: load for the full agent cycle and B/D/I interplay.references/context-sensitive-plans-as-agent-knowledge.md: load when plan structure and guard design are the main issue.references/selection-functions-as-agent-policy.md: load when priority, fairness, or risk tolerance need explicit policy treatment.references/intention-management-and-goal-decomposition.md: load when suspend/resume, subgoals, or intention auditability are central.references/failure-modes-in-bdi-systems.md: load when the current design already exists and you are debugging breakdowns.data-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.