ASTRA: BDI-Style Agent Language for Research

• ASTRA is a lightweight, BDI-style agent language that supports modular extensibility, robust Java integration, and both traditional and generative AI-driven agent platforms.
• It employs an AgentSpeak-inspired syntax for declaring beliefs, goals, and plans, facilitating rapid prototyping and practical application in multi-agent systems research.
• ASTRA’s design incorporates a dynamic module system and a runtime architecture that supports seamless sensor, actuator, and language extensions for real-world integration.

ASTRA is a lightweight, BDI-style agent-oriented programming language designed for research and teaching in multi-agent systems, with explicit goals of modular extensibility, familiar AgentSpeak-style syntax, robust Java integration, and pragmatic support for both traditional and generative AI-driven agentic platforms. It operationalizes the agent programming manifesto by providing high-level abstractions mapping directly onto beliefs, desires, and intentions (BDI), but remains practical for integration with real-world environments and modern software toolchains (Collier et al., 29 Jan 2026).

1. Design Goals and Underlying Philosophy

The ASTRA language is architected to enable modular, extensible agent programs using a well-defined “module” mechanism. This facilitates the introduction of new sensors, actuators, predicates, terms, or custom events. The syntax draws heavily from AgentSpeak, supporting declarations of beliefs, plans, and message-based (FIPA ACL) interactions. Key objectives include:

• Modularity and Extensibility: The module mechanism allows the dynamic registration of new capabilities, including domain-specific extensions.
• AgentSpeak Familiarity: The core constructs and plan syntax closely follow established BDI paradigms and AgentSpeak conventions, supporting rapid uptake by MAS researchers.
• Java Embedding: ASTRA agents can be embedded seamlessly in Java frameworks including EIS, CArtAgO, and standard GUI or communication libraries.
• Build and Packaging: Deep integration with Maven supports the development, packaging, and distribution of ASTRA agents as first-class Java artifacts.

These choices are rooted in the need for language-level support of high-level abstractions, while ensuring real-world applicability and ease of integration with evolving agentic and generative AI workflows (Collier et al., 29 Jan 2026).

2. Syntax, Language Constructs, and Programming Model

An ASTRA program consists of agent definitions comprising package/import declarations, belief bases, and plan rules. The plan rule syntax is:

$A$0

Key elements include:

• Beliefs: Stored as predicates (e.g., food("apples")) in a belief base.
• Goals: Achievement (!g(...)) and test (?q(...)) forms, invoked within plan bodies.
• Triggers: Events initiating plan selection, such as belief changes (+b, -b), goal adoption (+!g), or incoming messages (@message(performative, sender, content)).
• Plan Bodies: Sequences of primitive actions, goal invocations, belief updates, communication actions, test goals, control flow, and external calls.

The language is exemplified by code fragments such as:

$A$1

This shows familiar initial belief declarations and modular plan construction (Collier et al., 29 Jan 2026).

3. Formal Semantics and Execution Model

ASTRA’s operational semantics implement a standard BDI agent cycle. An agent’s state is modeled by the tuple $\langle A, B, G, \Pi \rangle$, where:

• $A$: queue of pending events (belief/goal changes, incoming messages)
• $B$: agent's belief base
• $G$: set of current intentions (each as a stack of plan instances)
• $\Pi$: plan library

Plan selection follows inference-rule execution. Upon receipt of an achievement goal event $+\!g$, the agent selects a plan $\pi$ whose trigger matches $+\!g$ and whose context holds under some substitution $\theta$:

$$\frac{ \langle +\!g,\; B,\; G,\; Π\rangle \quad \textit{selectPlan}(+\!g,\,Π)=\pi }{ \langle B,\; G,\; Π\rangle \longrightarrow \langle B,\; G\cup\{\langle\pi,\,\theta\rangle\},\; Π\rangle }$$

Execution proceeds via intention selection, step execution (belief updates, goal invocation, message sends, actuator calls), and repeats until all intentions are exhausted (Collier et al., 29 Jan 2026).

4. Runtime Architecture and Toolkit Composition

ASTRA applications are transpiled to Java, managed via Maven. The runtime system comprises:

• ASTRA Virtual Machine: Maintains belief base, event queue, intention scheduler, plan library.
• Module System: Enables dynamic addition of sensors (e.g., periodic polling), actuators (Java-invoked actions), terms/predicates (Java callbacks), and event sources.
• Standard Modules: Out-of-the-box support for console I/O, JSON handling, EIS/CArtAgO integration, and message brokering.
• astra.langchain4j Modules: Special-purpose modules for generative LLM integration. Includes:
  • OpenAI and Gemini Modules: Abstract LLM back-ends supporting loadApiKeyFromFile(...), initialize(params), chat(...).
  • Templater Modules: PromptTemplate, ResponseTemplate, CompositeTemplate for prompt construction, variable binding, response parsing.
  • BelRAG Module: RAGTemplate for retrieval-augmented generation, dynamically populating prompts from belief-derived facts.

This suggests a hybrid architecture leveraging BDI-level abstractions and modern generative AI service modules, composed through a unified agent module interface (Collier et al., 29 Jan 2026).

5. LLM Integration and Hybrid Agent Plans

The astra-langchain4j library allows seamless incorporation of LLM-based actions into ASTRA agent plans. For example:

$A$2

Principal integration features:

• Backend Initialization: LLM backends (e.g., OpenAI) are initialized at runtime with credentials.
• Prompt Engineering: Templater components enable parametric prompt construction and variable binding.
• RAG Support: Prompts can be filled dynamically from the agent’s beliefs via RAGTemplate.
• Response Parsing: Structured responses can be interpreted using response templates, with support for extracting specific content or structured data.

This functionality permits the direct invocation of LLMs as reasoning or generative components within declarative agent plans (Collier et al., 29 Jan 2026).

6. Representative Applications

Three archetypal applications illustrate ASTRA’s versatility:

a) Travel Planner (Round-Robin Group Chat)

• Special-purpose agents (“planner”, “local”, “language”, “summary”) engage in a collaborative itinerary construction.
• Orchestrator agent sets up roles and message order via FIPA Request protocol.
• Each assistant agent leverages LLM calls to generate partial solutions, returning responses via standard FIPA performative messages.
• Implements AutoGen-style “round-robin” group collaboration within ASTRA+FIPA ACL.

b) Tic-Tac-Toe (LLM-Assisted and Non-LLM)

• Agents hold board state as beliefs, requiring plan rules to satisfy test goal ?location(Row,Col).
• Baseline agent uses search over the belief-stored state.
• LLM-based agent uses prompt cycles and structured response parsing for move selection: “Can I lose?” queries and JSON move generation, integrating prompt templates with stepwise reasoning and belief updates.

c) Towerworld Block Stacking

• Uses the EIS module for environment interfacing.
• Block-on events trigger goal-directed tower construction, using multi-part prompt templates, belief-to-prompt RAG, and stepwise LLM-driven planning.
• Action execution is tightly synchronized via beliefs and environment signals, with LLM-generated JSON instructions parsed and dispatched to actuators.

These applications demonstrate direct mapping of generative “agentic AI workflow patterns” onto classical MAS paradigms and the flexibility of the LLM integration workflow (Collier et al., 29 Jan 2026).

7. Empirical Observations and Practical Lessons

Key findings from these explorations include:

• Ease of Integration: LLM calls are readily embedded in agent plans using existing Java LLM libraries (e.g., Langchain4j) through the ASTRA module system.
• Protocol Generalization: Many emergent “agentic AI workflow patterns” align with classical MAS protocols (notably FIPA Request), demonstrating continued relevance of established toolkits.
• Single-Agent Sufficiency: Not all complex workflows necessitate multi-agent deployments; reflective, single-agent orchestrators can express evaluator-optimizer loops.
• LLM Performance Limitations: Off-the-shelf LLMs currently underperform in domains requiring consistent, context-sensitive decision making (as in Tic-Tac-Toe, Towerworld) or non-trivial multi-step reasoning.
• Prompt Engineering Sensitivity: Outcomes are highly sensitive to prompt design; retrieval-augmented prompting offers some grounding but does not guarantee correctness.

A plausible implication is that, while agentic LLM integration is technically straightforward, achieving reliable, correct, and context-dependent machine reasoning remains a significant research challenge (Collier et al., 29 Jan 2026).