Evolutionary Lifecycle & Adaptive Quality

Concept & Purpose

AI models and automated scripts must follow software engineering standards to prevent uncoordinated updates. YAIFA structures the agent release loop into four distinct phases:

1. Draft (Design): Define agent properties, BDI slots, and port parameters without writing implementation code.
2. Learn (Training): Train local models using historic data sources or synthetic data streams.
3. Simulation (Quality Gate): Verify agent behaviors in a sandbox running regression tests.
4. Production (Release): Deploy compiled containers to hardware runtimes and operate independently.

Design (Draft) and Learn can be run through multiple times: refine structure → train → re-adjust — without re-inventing the entire agent. The simulation phase verifies logic and MAS behavior and prepares production operation; on updates it is repeated (regression).

Continuous Evolution — Agents That Never Stand Still

The lifecycle is not a one-way street that ends at Production. YAIFA is designed for continuous evolution: agents are improved, extended, and adapted throughout their entire operational lifetime — while they are running.

Key capabilities that enable continuous development:

• Iterative refinement loops: If a regression test fails in Simulation, the agent falls back to Draft or Learn for adjustment — without affecting the live system.
• Versioned BDI components: Beliefs, plans, and port-processing modules are individually versionable. You can exchange a single plan without rebuilding the entire agent.
• Hybrid implementations: Plans can be newly trained neural networks, Python programs, rule sets, or structured payloads — all within the same template. This lets you gradually increase automation levels as confidence grows.
• Lineage tracking: Old and new plan versions coexist in a lineage until simulation and release secure the transition. You always know which version is active and can roll back instantly.

This means an agent that starts as a simple rule-based assistant can evolve step by step into a fully autonomous cognitive system — each step validated, each transition safe.

Multiple Coexisting Plans — Flexibility, Resilience & Zero-Downtime Updates

A core strength of the BDI architecture is that any number of plans can be defined for an agent and coexist in parallel — not running simultaneously, but existing alongside each other as available solution methods. The agent selects the appropriate plan based on the current situation and its beliefs.

This coexistence of multiple plans unlocks three decisive advantages:

1. Zero-Downtime Updates During Live Operation

While one plan is active in production, a new or revised plan can be developed, trained, and tested in the simulation sandbox — without touching the live system:

Plan	Role	State
Active Plan	The currently productive plan — handles all live decisions and actions on the shopfloor.	status: production
Shadow Plan	The next version — passes through Draft → Learn → Simulation, without touching the live system.	status: simulation

The update workflow:

1. Develop: While the active plan keeps production running, the new plan is developed, trained, and tested in the simulation sandbox.
2. Validate: The new plan runs the full regression test suite against mock inputs. All BDI state changes and outputs are verified.
3. Human sign-off: The Human-in-the-Loop gateway requires explicit approval before the new plan goes live.
4. Atomic switch: On approval, the new plan is promoted to production and the previous plan is demoted to a standby lineage version. The switch is atomic — no downtime, no interrupted cycles.
5. Instant rollback: If the new plan behaves unexpectedly in production, the previous plan can be reactivated immediately from the lineage. The agent reverts in a single cycle.

2. Resilience Through Fallback Plans

When a plan fails or produces unsatisfactory results, the agent can fall back to another coexisting plan and continue operating. This means:

• Graceful degradation: If a complex AI-based plan encounters an edge case it cannot handle, a simpler rule-based plan can take over — the agent keeps working instead of failing.
• Continuous operation: Failed attempts do not bring the system to a halt. The agent switches to an alternative solution method and maintains productivity.
• Confidence-based selection: The agent can choose between plans based on confidence scores, environmental conditions, or explicit business rules.

3. Heterogeneous Solution Methods

Plans are not limited to a single implementation type. Any solution method can be defined as a plan, including:

• Rule-based logic: Deterministic Python rules for well-understood, stable processes.
• Neural networks: Trained models for pattern recognition, prediction, and complex decision-making.
• Human-in-the-Loop: A plan that escalates decisions to a human operator via the HITL gateway — ideal for high-impact or ethically sensitive actions.
• LLM-based reasoning: A plan that leverages local or external LLMs for natural-language understanding, complex reasoning, or unstructured data processing.
• Hybrid combinations: Multiple methods within a single plan — e.g. a neural network for perception, rules for safety constraints, and HITL for final approval.

This lets you gradually increase automation: start with a conservative rule-based plan, add an AI plan as a coexisting alternative, validate it in simulation, and switch over when confidence is high — while the rule-based plan remains available as a permanent fallback.

End-to-End: From Template to Plant

Each phase utilizes specific configuration formats and generated assets to enforce separation of concerns:

Phase	Professional Purpose	Typical Building Blocks
Design	Define structure of network and each agent.json, flow, sub-MAS, catalog agents; Wiki + component catalog + LLM filling.	Catalog (FR-KIT-), Templates (FR-FLOW-08, FR-AGT-AI-05), Scoped Wiki.
Learn	Train various models (per port/processing) on training data.	yaifa_agent_learn.py, *_Source_Learn.py, agent-wide training_data_source_*.
Simulation	Release gate before production; later repeated tests on changes.	yaifa_agent_sim.py, MAS-Sandbox, FR-AGT-LC-03.
Production	Productive run in target environment.	FR-PROD-02/03, Productive Exchange types; no LLM on the PLC in normal case.

Lifecycle Phase Details

Each phase utilizes specific workspace states and validation gates:

Phase	Workspace State	Key Deliverables	Validation Gate
I. Design	status: draft	agent.json, empty port stubs, project wiki pages.	JSON Schema validation of the agent configuration.
II. Learn	status: learn	yaifa_agent_learn.py, trained model weights (.pkl, .onnx).	Loss metric evaluation and training data checks.
III. Simulation	status: simulation	yaifa_agent_sim.py, sandbox blackboards, mock streams.	Automated test cases regression (Simulation-Pass).
IV. Production	status: production	yaifa_agent.py (live driver), Docker-image, runbook.	Human-in-the-loop (HITL) manual sign-off.

Development loops are iterative. If a regression test fails in the Simulation phase, the agent falls back to Draft to adjust structures or Learn to retrain weights, avoiding live deployment errors. Crucially, this fallback only affects the shadow plan — the active production plan continues running undisturbed.

Technical Realization

The agent's current stage is tracked in the workspace database and reflected in the agent.json metadata block:

{
  "id": "agent_robot_packer",
  "version_index": 4,
  "status": "simulation",
  "capability_level": "deliberative",
  "active_plan": {
    "version": "v4.2",
    "status": "production"
  },
  "shadow_plan": {
    "version": "v4.3",
    "status": "simulation"
  },
  "governance_tags": {
    "owner": "assembly_line_manager",
    "cost_center": "CC-9021"
  }
}

Depending on the status, the YAIFA runner loads the appropriate execution driver (yaifa_agent_learn.py, yaifa_agent_sim.py, or yaifa_agent.py) to prevent development telemetry or experimental training loops from executing on productive physical machinery.

BDI objects are versionable components — individual parts (e.g. only the plan) can be exchanged; old and new plan can coexist in a lineage until simulation and release secure the transition. Beliefs, Plans, and Port-Processing can be newly trained neural networks, Python programs, rules, and structured payloads — hybrid in the same template.