Built on the BDI Concept

Concept & Purpose

Typical LLM agent frameworks rely entirely on prompts, which leads to unpredictable behavior, hallucinations, and loops. YAIFA solves this by anchoring agent deliberation inside the Belief-Desire-Intention (BDI) model, a classical architecture in artificial intelligence:

• Beliefs: The agent's knowledge model of its environment (e.g. system status, sensor logs, historical databases).
• Desires: The objectives the agent wants to satisfy (e.g. "optimize batch throughput" or "reduce energy cost").
• Intentions: The concrete plans of action that the agent is committed to executing to satisfy its current desires.

Practical Value

BDI separates what the agent knows from what the agent does, offering major operational advantages:

Benefit	Traditional Prompt Agent	YAIFA BDI Agent
Explainability	Black-box text generation. Hard to verify why an action was taken.	Strict audit trail. Each step log details: Beliefs → Desire → Intention → Action.
Parallel execution	Single execution path. Confused by concurrent requirements.	Runs multiple plans with varying levels of automation concurrently.
Predictability	High stochastical drift. Output changes unpredictably over updates.	Code-validated BDI gates and strict schema checks before action.

BDI Element Classes — Typed and Enforceable

Every Observe port, Action port, and BDI row (Belief, Desire, Plan) can reference an element class — a JSON catalog entry describing capabilities and requirements. Requirements split into two layers:

Layer	Question	When evaluated
Structural	What must the agent topology and data shapes provide so a desire/plan can be adopted or a relation patch applied?	Design time (Studio, CI), relation ingress, before desire/plan revise.
Environmental	What runtime context must hold to log an intention or select a plan?	Runtime BDI hooks (deliberation, intention_commitment, plan_commitment).

Classification makes BDI typed and enforceable — the LLM fills rows with element_class_id; Studio, CI, and Runtime check the same rules. Rejections land in BDI Runtime Logs and flow into the improvement loop (new Beliefs, Desires, Plans).

BDI Structure as Basis for Traceability

The BDI structure in the YAIFA framework is not only a functional architecture but also the foundation for transparency:

• Beliefs (Knowledge): All assumptions of the agent about the world are documented and visible to humans.
• Desires (Goals): Clear definition of what the agent is supposed to achieve.
• Intentions (Actions): The chosen path to goal achievement is traceable through continuous logging.

Every solution method within YAIFA is accompanied by structured logging. Logs capture not only the "what" but also the "why" through the BDI structure (e.g., "Based on Belief X and Desire Y, Intention Z was chosen").

Technical Realization

YAIFA implements BDI using structured, generated handlers that process state updates in a loop:

# Inside generated agent_main_generator BDI loops
def deliberate(context):
    # 1. Update beliefs from port inputs
    beliefs = process_beliefs(context)

    # 2. Filter desires (what goals are active under current beliefs)
    active_desires = filter_desires(beliefs)

    # 3. Commit to intentions (select best plan for active desires)
    committed_intention = select_intention(active_desires, beliefs)

    # 4. Execute plan instructions
    result = execute_plan(committed_intention)
    return result

YAIFA uses Element Classes to typecheck desires and plans at runtime. Before an intention is committed, structural and environmental checks are run to ensure that the plan matches safety conditions and operational parameters defined in the agent.json schema.