Acceptance Patterns

Acceptance is up to the developer. The framework gives the agent governed candidate material; the agent decides whether to accept, reject, review, refine, or explicitly materialise selected fields through its host platform.

The Core Principle

Large Language Models act as probabilistic generators, producing outputs that cannot be trusted implicitly. Generative Layers addresses this by keeping raw outputs as candidate material outside the host agent's belief base. The host agent operates as a symbolic gatekeeper: it inspects fields, records peer review or other evidence, previews admissibility, and then records a final accept or reject decision. Acceptance does not automatically insert a BDI belief; it makes the candidate accepted GL-side knowledge, after which the host agent may explicitly materialise selected fields using its own belief-update or domain-action mechanisms.

View current examples repository
Candidate lifecycle
LLM result -> candidate -> evidence/admissibility -> explicit accept/reject.
Cross-platform parity
ASTRA, Jason, and JaCaMo expose the same conceptual lifecycle through different syntax.
Current code snippets
Snippets below are loaded from the current examples repository.

Implemented Acceptance Patterns

The following patterns are reusable implementation patterns. They show concrete ways to validate, inspect, review, refine, compare, accept, or reject candidate material using the same governance lifecycle across ASTRA, Jason, and JaCaMo. Any update to the host belief base remains an explicit step in the agent program.

Loading current pattern examples from GitHub...

Application-Level Governance Blueprints

The blueprints below show application designs for developers and future research work, using command combinations to compose larger governed BDI architectures.

Conceptual Architecture Blueprints & Research Directions
Project 1 — Multi-Agent Software Engineering Swarm (Autonomous Plan-Execution Loops)
Domain: Automated Code Generation & Quality Control.
How it works: A decentralized multi-agent BDI system simulating software engineering roles, cooperating through belief-sharing and self-correcting feedback cycles to produce and audit code assets.
Command Combinations:
  • Product Owner Agent: Uses call(poBind, "backlog", "llm.answer", "ANSWER", specPrompt, "stories", projectContext) to draft backlog material; candidate(storyRes) resolves the candidate and get(storyCand, "stories") extracts generated stories.
  • Developer Agent: Uses call(devBind, "implement_story", "llm.answer", "ANSWER", storyPrompt, "code,language", devContext) to produce candidate code, then resolves the candidate with candidate(codeRes).
  • Tester Agent: Compiles and tests the generated code outside GL; it may use check(codeRes) only for GL validation/status, then records test evidence with judge(codeCand, "tester", verdict, confidence, rationale), where the verdict is APPROVE or REJECT_VERDICT.
  • Security Auditor Agent: Runs static/security checks outside GL and records the audit with judge(codeCand, "security_auditor", verdict, confidence, rationale), using the same verdict values.
  • Governance Plan: Evaluates decide(codeCand). If inadmissible, it calls reject(codeCand, "failed audit") and starts a new corrective call. If admissible, it calls accept(codeCand, "all checks passed"); the host agent then stores, builds, or publishes the code through its own domain plan.
Project 2 — Self-Optimizing RAG-based Clinical Assistant (Safe Epistemic Foundations)
Domain: Healthcare & Safety-Critical Diagnostics.
How it works: A diagnostic support system that guards the agent's epistemic state by isolating generated clinical support material, verifying it against trusted scientific repositories, and recording an adoption decision before any explicit BDI/domain adoption.
Command Combinations:
  • Triage Agent: Uses call(triageBind, "clinical_lookup", "llm.answer", "ANSWER", symptomsPrompt, "lookup_keys", "") to generate search terms; candidate(keyRes) and get(keyCand, "lookup_keys") expose them to the search plan.
  • Search Agent: Queries trusted clinical repositories outside GL and may assert retrieved papers into the local BDI belief base through normal host-agent adoption logic.
  • Diagnostic Agent: Uses call(diagBind, "draft_report", "llm.answer", "ANSWER", patientPrompt, "finding,risk,citations", evidenceContext) to produce a candidate report, then resolves it with candidate(diagRes).
  • Safety Review: Reads fields with get(diagCand, "citations") and get(diagCand, "risk"), checks them against trusted evidence outside GL, then records evidence with judge(diagCand, "safety_auditor", verdict, confidence, rationale).
  • Resolution Plan: Evaluates decide(diagCand). If inadmissible, it calls reject(diagCand, "unsupported report"); if admissible, it calls accept(diagCand, "verified report") before any explicit BDI/domain adoption of the report.
Project 3 — E-Commerce Arbitrage & Negotiating Agent (Decentralized Game-Theoretic Plan Harmonization)
Domain: Autonomous Trading & Game Theory.
How it works: An automated trading agent that negotiates wholesale supplier contracts, enforcing hard financial spending limits before any external offer is sent.
Command Combinations:
  • Scouter Agent: Uses call(scoutBind, "market_scan", "llm.answer", "ANSWER", marketPrompt, "item,price,trend", marketContext), resolves candidate(marketRes), and extracts opportunity fields with get.
  • Negotiator Agent: Uses call(negotiatorBind, "counter_offer", "llm.answer", "ANSWER", negotiationPrompt, "offer,price", negotiationContext) to draft a candidate counter-offer.
  • Budget Guard: Extracts get(offerCand, "price"), checks the proposed price against the agent's budget rules outside GL, and records the result with judge(offerCand, "budget_guard", verdict, confidence, rationale).
  • Commit Plan: Evaluates decide(offerCand). If inadmissible, it calls reject(offerCand, "outside budget"); if admissible, it calls accept(offerCand, "within budget"), after which the host agent may commit or send the contract through its own domain action.
Project 4 — Autonomous Incident Response Grid (Self-Healing Cyber-Physical Systems)
Domain: IoT, Energy Logistics, & Emergency Mitigation.
How it works: A self-healing grid-management system modeled using BDI agents, coordinating dynamically to identify cyber-physical anomalies, draft load-routing configurations, and execute plans to bypass physical line faults safely.
Command Combinations:
  • Monitor Agent: Receives real-time telemetry from smart sensors and updates BDI beliefs or recovery goals outside GL.
  • Planner Agent: Uses call(plannerBind, "route_plan", "llm.answer", "ANSWER", anomalyPrompt, "route,load_estimate", gridContext) to generate a candidate routing plan and resolves it with candidate(routeRes).
  • Validation Guard: Runs a simulation outside GL using get(routeCand, "route") and get(routeCand, "load_estimate"), then records the simulation result with judge(routeCand, "load_simulator", verdict, confidence, rationale).
  • Decision Loop: Evaluates decide(routeCand). If inadmissible, it calls reject(routeCand, "capacity violation predicted") and issues a new corrective call. If admissible, it calls accept(routeCand, "safe route confirmed"); only then may the host agent execute the recovery action through its own domain layer.
Project 5 — Interactive NPC Dynamic Dialogue System (Emergent Narrative & Social Interaction)
Domain: Gaming & Creative Entertainment.
How it works: Virtual game characters with distinct personality profiles and social beliefs, generating contextually appropriate dialogue while auditing responses to ensure compliance with established world lore and behavioral bounds.
Command Combinations:
  • Perception Agent: Records player choices and updates social relationship beliefs within the BDI belief base outside GL, for example player_relation(NPC, player, hostile).
  • Dialogue Agent: Uses call(dialogueBind, "npc_dialogue", "llm.answer", "ANSWER", dialoguePrompt, "dialogue,tone", sceneContext) to generate a candidate dialogue line and resolves it with candidate(dialogueRes).
  • Lore Auditor: Reads get(dialogueCand, "dialogue") and get(dialogueCand, "tone"), checks them against world lore and content policy outside GL, then records the result with judge(dialogueCand, "lore_auditor", verdict, confidence, rationale).
  • Adopt & Speak: Evaluates decide(dialogueCand). If admissible, the agent calls accept(dialogueCand, "lore compliant") and then records or speaks the line through its own game-domain action; otherwise, it calls reject(dialogueCand, "lore or tone violation") and starts a retry plan.