Download the PHP package kkphoenix/panteao without Composer

Panteão BDI - MAS Globalization

Panteão is a framework that envelops the Jason interpreter to decouple BDI cognitive logic. The primary advantage of this framework is its native support for JaCaMo—we are not reinventing the wheel, but rather exposing the BDI world to every programming language. This framework acts as an envelope, solving encapsulation problems and providing robust environment solutions. The BDI cognitive cycle runs in a dedicated engine process while applications communicate with the agents using the Panteao SDK for their language.

Running the Engine

The engine can be executed either programmatically using the package library of your language or as a standalone process from the terminal.

Standalone Executable

The core BDI interpreter can be started from the command line using the compiled executable binary:

Parameters:

• Path to the JaCaMo project file (.jcm).
• Port number to listen for incoming application connections.

Programmatic Integration

For applications that embed the BDI interpreter directly inside their codebase, the library wrappers (SDKs) will automatically download the correct engine binary for your platform and manage the background process lifecycle seamlessly when the engine instance is initialized. This enables programmatic control of the engine startup, shutdown, and event mapping without requiring any manual installation or setup on the host machine.

Catch-All Action Listener (Wildcard / Proxy Mode)

All 18 SDKs support a global wildcard action listener (onAnyAction / on_any_action). This is extremely useful when building Gateway/Proxy architectures (like a Tauri application or a Unity Game), where your backend simply routes raw JSON strings to the frontend without needing to know every possible action explicitly:

Writing Agent Code

The BDI architecture is configured through JaCaMo files and AgentSpeak plans.

JaCaMo Project File

With this framework, CArtAgO is completely decoupled from Jason and Moise—your own system architecture becomes the environment!

Define the Multi-Agent System configuration (ex: project.jcm):

AgentSpeak File

Define beliefs, plans, and actions for your agents (ex: orquestrador.asl):

When an agent schedules an action, the engine dispatches the request to the connected application.

Moise Organizational Support

Panteão provides native support for the Moise organizational model by including Moise and CArtAgO dependencies in the engine classpath. While CArtAgO is used internally to instantiate standard Moise organizational artifacts (such as GroupBoard, SchemeBoard, and OrgBoard) in memory, all other system actions are routed to your application clients. This guarantees that agents can adopt roles, execute group missions, and comply with norms using standard Moise directives and XML configurations out-of-the-box.

Speech Acts and ILF

Panteao supports the full range of KQML-inspired speech acts and illocutionary forces (ILF) native to the Jason interpreter. This enables sophisticated communication between the engine, external application clients, and other agents. When a message is sent or received, the SDK routes the speech act directly to registered handlers or event listeners.

The supported ILFs are:

• tell: The sender intends the receiver to believe that the content is true.
• untell: The sender intends the receiver to drop the belief that the content is true.
• achieve: The sender requests the receiver to try to achieve a state where the content is true.
• unachieve: The sender requests the receiver to drop the intention of achieving the state where the content is true.
• tellHow: The sender shares a plan with the receiver.
• untellHow: The sender requests the receiver to delete a plan from its plan library.
• askIf: The sender wants to know if the content is currently true for the receiver.
• askAll: The sender wants all answers to a query from the receiver.
• askHow: The sender wants all plans matching a triggering event from the receiver.

Important Q&A and Architectural Decisions

How is the engine packaged and what is its footprint?

The BDI engine is compiled into a standalone native binary using GraalVM. This native binary is self-contained and does not require a Java Runtime Environment (JRE) to be installed on the host system. The binary is around 68MB in size because it bundles the substrate VM, the Jason interpreter, the Moise parser, the CArtAgO runtime backend, and the TCP socket interface.

Automatic Engine Provisioning: You do not need to download, compile, or install the engine manually! When you install an SDK package (e.g., npm install panteao-js or cargo add panteao-client), the SDK will automatically resolve and download the correct native binary (via packages like panteao-engine-linux-x64) for your exact Operating System and CPU Architecture. The SDK then seamlessly spawns and manages this background binary for you.

If your corporate compliance policies prohibit running native binaries, the engine can also be executed as a standard Java JAR file using any enterprise-certified JDK.

What is the size of the SDK dependency?

The client SDK packages (available for all 18 supported languages) are extremely small, typically under 50KB. They contain zero Java libraries, zero JAR files, and have no external dependencies. The SDK acts as a lightweight client that manages connection parameters, background threads, socket reconnection, and message parsing over a fast local TCP loopback.

How is WebAssembly browser support structured?

Web browser execution is enabled by Leaning Technologies' CheerpJ, which runs the compiled JVM bytecode directly inside the browser using WebAssembly. The CheerpJ runtime is lazily loaded via dynamic ES module imports, ensuring it does not bloat the initial application download size. The engine shadow JAR (~7MB) is downloaded on-demand and cached in the browser's IndexedDB for instant subsequent boots. Interaction between the BDI engine and the browser DOM is handled by a JNI bridge with sub-millisecond latency. Browser execution is recommended for admin panels, simulation tools, and developer playgrounds running on desktop environments, like videogames with complex NPCs, whereas mobile or consumer-facing apps should connect to a remote engine instance using the lightweight socket SDK.

How does the engine scale and handle failures?

By decoupling the cognitive cycle from the application logic, the reasoning engine and the web API processes run independently. If the web server experiences a CPU spike or database lock, the BDI reasoning loop remains active. Under Kubernetes, the engine can be deployed as a sidecar container alongside the API pod. With a native binary memory footprint of 12MB, running multiple sidecar instances introduces negligible memory overhead. The client SDKs include automatic reconnection routines with exponential backoff and local perception queues to ensure message delivery during engine restarts.

How can I debug the agents' minds (Mind Inspector)?

Panteão supports the native Jason Mind Inspector, a web interface to visualize agents' beliefs, goals, and plans in real-time. For security and performance reasons, the web server is completely disabled by default in production. To enable it during development, you must pass the dev flag (e.g. dev=True or dev: true) to your SDK constructor when spawning the engine:

When enabled, the engine will print the Mind Inspector URL (typically http://localhost:3271) to the console on startup. If you are using an unsupported language or a custom wrapper, you can enable it by setting the PANTEAO_DEV=1 environment variable (.env file) before executing the engine.

Performance & Corporate Impact

Comparing JVM-based deployment against GraalVM native binary deployment.

Evaluation Metrics

[!IMPORTANT] Custom and Community Libraries Support: The compiled GraalVM native binary (panteao-engine) runs in a closed-world environment under GraalVM, meaning it cannot load arbitrary/custom classes at runtime. If your project uses custom agent architectures, custom environments, or third-party community libraries (e.g., libraries not pre-compiled into panteao-engine), you must run the engine using the JAR version (JVM mode) which supports dynamic classloading in the classpath.

Integration SDKs

To communicate with the BDI engine, applications use the official SDK package for their respective language. The SDK handles connection parameters, background threads, and action routing.

Python

Install the package:

Boilerplate code:

Go

Install the package:

Boilerplate code:

JavaScript / Node.js

Install the package:

Connection Client

TypeScript

Install the package:

The package ships with full TypeScript types built-in — no need to install a separate @types/ package.

Exported Types

Connection Client

Rust

Add the dependency to Cargo.toml:

Boilerplate code:

Java

Add the dependency:

Boilerplate code:

Kotlin

Add the dependency:

Boilerplate code:

Scala

Add the dependency:

Boilerplate code:

C

Link the library:

Boilerplate code:

C++

Download the SDK tarball from GitHub Releases or include the repository in your project.

Link the library in your CMakeLists.txt:

Boilerplate code:

C

Add the package:

Boilerplate code:

Dart

Add the package:

Boilerplate code:

PHP

Install the package:

Boilerplate code:

Ruby

Install the gem:

Boilerplate code:

Swift

Add Swift Package Manager dependency:

Boilerplate code:

Objective-C

Add the pod:

Boilerplate code:

R

Install the package:

Boilerplate code:

Bash / Shell

Install the helper:

Boilerplate code:

Custom Language Integration

If you want to integrate the Panteão BDI framework with a programming language that does not have an official SDK wrapper, refer to the UNSUPPORTED_LANGUAGES.md guide. It outlines the raw JSON socket protocol schema, speech acts, action execution callbacks, and includes lightweight connection examples (e.g., in COBOL).

For Developers

This section is dedicated to developers working on the Panteão BDI framework core, building it from source, or implementing custom language integrations.

Minimum Requirements

To build and run the engine, you need:

• Java Development Kit (JDK) 17 (required for CheerpJ WebAssembly browser target compatibility).
• Node.js (version 18 or newer) for SDK packaging and Node CLI execution.
• Docker (optional, for running integration test containers).

Compilation and Build Instructions

You can build the Java/BDI core from source using the following commands:

• Generate the Fat JAR: Builds the standalone JAR with all dependencies:

  The generated JAR file is located at build/libs/jason-ipc-all.jar.

• Build Everything and Copy Native Executable: Builds the JAR and compiles the optimized native image (using GraalVM native-image if configured on your host system):

  This command will compile and output the native binary panteao-engine directly inside the bin directory.

Global CLI Installation

Panteão provides a Node.js CLI launcher. You can link and install the CLI globally on your system to run MAS projects easily:

Once installed, you can launch the BDI engine with any .jcm or .mas2j file using the panteao command:

The CLI launcher automatically handles classpath discovery, generates temporary MAS2J files for project configurations, and starts either the native binary (if compiled) or falls back to the Java bytecode runner.

Note: By default, the programmatic SDK wrappers will attempt to fall back to running the Java JAR engine if the native executable is not found. To enforce strict execution of the GraalVM native binary only (preventing the JAR fallback), configure the useJarFallback option to false in your client initialization (e.g. new Panteao({ useJarFallback: false })).

Docker Integration

To compile and package the Panteão BDI engine inside an isolated Docker container, run:

To execute the engine inside a Docker container while exposing the TCP loopback port (e.g. 0):

How to Run the Test Suite

The repository contains scripts for local and containerized integration testing:

• Local JS Tests: Runs the Node.js SDK tests sequentially measuring execution latency:

• Multi-Language Docker Tests (Dilúvio): Runs the integration tests across all 18 programming languages in isolated containers:

• Complete Test Suite and Report Generation: Executes all JS and multi-language tests, generating a consolidated markdown report at metrics_report.md:

Repository Structure

• src/main/java: Java source code for the Panteão core, socket environment, browser CheerpJ bridge, and launcher.
• bin: Shell and Node.js launcher executables and target output directory for native compilation.
• sdk: Client library implementations for all supported programming languages.
• test: Integration test suites, ASL agent behaviors, JCM projects, and the Dilúvio containerized test environment.

Communication Protocol Architecture

Decoupled messaging architecture between the BDI reasoning engine and custom application SDK clients: