Definition

An AI Agent is an autonomous software entity that perceives its environment through sensors or data inputs, maintains an internal model of the world, reasons about its observations using artificial intelligence techniques (machine learning, rule systems, planning algorithms, or large language models), and takes actions to achieve specified goals. Unlike passive software components that respond only when called, AI agents operate with varying degrees of independence -- monitoring conditions, making decisions, initiating actions, and adapting their behavior based on feedback. The degree of autonomy ranges from simple reactive agents that follow fixed rules to fully autonomous agents capable of learning, planning, and self-modification.

Overview

The concept of an AI agent unifies two foundational ideas in computer science: the notion of a software agent (an autonomous entity acting on behalf of a user or system) and the techniques of artificial intelligence (the ability to perceive, reason, learn, and act). The theoretical foundation was formalized by Stuart Russell and Peter Norvig in their classification of agent types by increasing sophistication: simple reflex agents, model-based reflex agents, goal-based agents, utility-based agents, and learning agents.

In practice, modern AI agents have evolved far beyond these textbook categories. The emergence of large language models (LLMs) has created a new class of AI agent that can understand natural language instructions, reason about complex tasks, generate code and text, and interact with external tools and APIs. These LLM-powered agents combine the flexibility of natural language understanding with the precision of programmatic tool use, creating systems capable of tackling tasks that previously required human judgment.

The Prismatic Platform implements 530+ AI agents organized under the AIAD (AI Agent Definition) standard. Each agent is specified declaratively with its capabilities, authority level, communication protocols, and operational constraints. The agents span 16 domains -- from security operations (Color Team) to quality assurance (autoevolve/autoheal) to intelligence gathering (OSINT) to formal verification (White Team). This represents one of the largest production deployments of coordinated AI agents, running on the Erlang/OTP BEAM virtual machine for maximum fault tolerance and concurrency.

Agent Classification

Classification	Perception	Decision Making	Learning	Example
Simple Reflex	Current percept only	Condition-action rules	None	Alert threshold monitors
Model-Based	Maintains world model	Rules + internal state	None	Drift detectors with baseline
Goal-Based	World model + goals	Search/planning	None	Task-oriented workflow agents
Utility-Based	World model + utility function	Expected utility maximization	None	Resource allocation optimizers
Learning	All of above + feedback	Adapts based on experience	Online/offline	Autoevolve quality improvers
LLM-Powered	Natural language + tools	Reasoning + tool use	In-context learning	Archer Supreme, Red Commander

The AIAD Agent Anatomy

Every AI agent in the Prismatic Platform follows the AIAD standard specification:

# AIAD Agent Specification Structure
agent-spec:
  name: "agent-name"
  version: "1.0.0"
  tier: L3  # L1 Strategic through L5 Autonomous
  domain: "security"
  capabilities:
    - capability_1
    - capability_2
  protocols:
    input: [structured_message, natural_language]
    output: [structured_report, action_directive]
  constraints:
    max_autonomy: "bounded"
    requires_approval: ["destructive_actions"]
    sandbox: true
  enforcement:
    doctrine: "no-mercy-no-doubts"
    version: "2.0.0"
    compliance: mandatory

Technical Details

Agent Architecture

The core architecture of an AI agent follows the perceive-decide-act cycle, implemented in Elixir/OTP as a GenServer process:

defmodule PrismaticAgents.Agent do
  @moduledoc """
  Base module for AI agents in the Prismatic Platform.
  Implements the perceive-decide-act cycle as an OTP GenServer
  with configurable perception, reasoning, and action modules.
  """

  use GenServer

  @type agent_state :: %{
    id: String.t(),
    name: String.t(),
    tier: :l1 | :l2 | :l3 | :l4 | :l5,
    domain: atom(),
    world_model: map(),
    goals: list(map()),
    capabilities: list(atom()),
    history: list(map()),
    status: :idle | :perceiving | :reasoning | :acting | :error
  }

  @callback perceive(agent_state()) :: {:ok, list(map())} | {:error, term()}
  @callback reason(agent_state(), list(map())) :: {:ok, map()} | {:error, term()}
  @callback act(agent_state(), map()) :: {:ok, map()} | {:error, term()}

  @spec start_link(keyword()) :: GenServer.on_start()
  def start_link(opts) do
    name = Keyword.fetch!(opts, :name)
    GenServer.start_link(__MODULE__, opts, name: via_tuple(name))
  end

  @impl GenServer
  def init(opts) do
    state = %{
      id: generate_agent_id(),
      name: Keyword.fetch!(opts, :name),
      tier: Keyword.get(opts, :tier, :l4),
      domain: Keyword.fetch!(opts, :domain),
      world_model: %{},
      goals: Keyword.get(opts, :goals, []),
      capabilities: Keyword.get(opts, :capabilities, []),
      history: [],
      status: :idle
    }

    :telemetry.execute(
      [:prismatic_agents, :agent, :started],
      %{},
      %{agent_id: state.id, name: state.name, tier: state.tier}
    )

    {:ok, state}
  end

  @spec execute(GenServer.server(), map()) :: {:ok, map()} | {:error, term()}
  def execute(agent, task) do
    GenServer.call(agent, {:execute, task}, :infinity)
  end

  @impl GenServer
  def handle_call({:execute, task}, _from, state) do
    state = %{state | status: :perceiving}

    result =
      with {:ok, percepts} <- apply_perceive(state, task),
           state <- update_world_model(state, percepts),
           state <- %{state | status: :reasoning},
           {:ok, decision} <- apply_reason(state, percepts),
           state <- %{state | status: :acting},
           {:ok, action_result} <- apply_act(state, decision) do
        state = record_history(state, task, decision, action_result)
        {:ok, action_result}
      end

    final_state = %{state | status: :idle}
    {:reply, result, final_state}
  end

  @spec update_world_model(agent_state(), list(map())) :: agent_state()
  defp update_world_model(state, percepts) do
    updated_model =
      Enum.reduce(percepts, state.world_model, fn percept, model ->
        Map.merge(model, percept.data, fn _key, old, new ->
          if percept.timestamp > Map.get(old, :timestamp, ~U[1970-01-01 00:00:00Z]) do
            new
          else
            old
          end
        end)
      end)

    %{state | world_model: updated_model}
  end
end

LLM-Powered Agent Implementation

Modern AI agents increasingly leverage large language models for natural language reasoning:

defmodule PrismaticAgents.LLMAgent do
  @moduledoc """
  AI agent implementation powered by large language models.
  Combines LLM reasoning with structured tool use for
  flexible, natural-language-directed task execution.
  """

  @behaviour PrismaticAgents.Agent

  @type tool :: %{
    name: String.t(),
    description: String.t(),
    parameters: map(),
    handler: (map() -> {:ok, term()} | {:error, term()})
  }

  @spec execute_with_llm(map(), list(tool()), keyword()) ::
          {:ok, map()} | {:error, term()}
  def execute_with_llm(task, available_tools, opts \\ []) do
    model = Keyword.get(opts, :model, "claude-opus-4-6")
    max_iterations = Keyword.get(opts, :max_iterations, 10)
    temperature = Keyword.get(opts, :temperature, 0.0)

    system_prompt = build_system_prompt(task, available_tools)

    iterate_reasoning_loop(
      system_prompt,
      task.input,
      available_tools,
      max_iterations,
      [],
      model,
      temperature
    )
  end

  @spec iterate_reasoning_loop(
          String.t(), map(), list(tool()), non_neg_integer(),
          list(map()), String.t(), float()
        ) :: {:ok, map()} | {:error, term()}
  defp iterate_reasoning_loop(_prompt, _input, _tools, 0, history, _model, _temp) do
    {:error, %{reason: :max_iterations_exceeded, history: history}}
  end

  defp iterate_reasoning_loop(prompt, input, tools, remaining, history, model, temp) do
    with {:ok, response} <- call_llm(prompt, input, history, model, temp),
         {:ok, parsed} <- parse_llm_response(response) do
      case parsed do
        %{type: :final_answer, content: answer} ->
          {:ok, %{answer: answer, iterations: length(history) + 1, history: history}}

        %{type: :tool_call, tool: tool_name, args: args} ->
          with {:ok, tool} <- find_tool(tools, tool_name),
               {:ok, tool_result} <- tool.handler.(args) do
            new_history = history ++ [%{
              role: :assistant,
              content: response,
              tool_call: %{name: tool_name, args: args, result: tool_result}
            }]

            iterate_reasoning_loop(prompt, input, tools, remaining - 1, new_history, model, temp)
          end
      end
    end
  end
end

Agent Tier System

The five-tier agent hierarchy defines authority levels and operational constraints:

defmodule PrismaticAgents.TierSystem do
  @moduledoc """
  Defines and enforces the five-tier agent authority hierarchy.
  Each tier has specific permissions, autonomy limits, and
  escalation requirements.
  """

  @type tier :: :l1 | :l2 | :l3 | :l4 | :l5

  @tier_definitions %{
    l1: %{
      name: "Strategic",
      autonomy: :supreme,
      can_orchestrate: [:l1, :l2, :l3, :l4, :l5],
      requires_approval: [],
      max_concurrent_tasks: :unlimited,
      examples: ["archer-supreme", "supreme-coordinator"]
    },
    l2: %{
      name: "Tactical",
      autonomy: :high,
      can_orchestrate: [:l2, :l3, :l4, :l5],
      requires_approval: [:cross_domain_operations],
      max_concurrent_tasks: 50,
      examples: ["red-commander", "blue-commander"]
    },
    l3: %{
      name: "Operational",
      autonomy: :medium,
      can_orchestrate: [:l3, :l4, :l5],
      requires_approval: [:destructive_actions, :external_communication],
      max_concurrent_tasks: 20,
      examples: ["purple-coordinator", "white-verifier-commander"]
    },
    l4: %{
      name: "Specialist",
      autonomy: :bounded,
      can_orchestrate: [:l5],
      requires_approval: [:state_modification, :external_calls],
      max_concurrent_tasks: 5,
      examples: ["gray-edge-finder", "blue-drift-detector"]
    },
    l5: %{
      name: "Autonomous",
      autonomy: :narrow,
      can_orchestrate: [],
      requires_approval: [:all_non_read_operations],
      max_concurrent_tasks: 1,
      examples: ["health-checker", "background-monitor"]
    }
  }

  @spec authorize(tier(), atom()) :: :authorized | {:denied, String.t()}
  def authorize(tier, action) do
    tier_def = Map.fetch!(@tier_definitions, tier)

    cond do
      action in tier_def.requires_approval ->
        {:denied, "Action #{action} requires approval for tier #{tier}"}

      true ->
        :authorized
    end
  end

  @spec can_orchestrate?(tier(), tier()) :: boolean()
  def can_orchestrate?(orchestrator_tier, target_tier) do
    tier_def = Map.fetch!(@tier_definitions, orchestrator_tier)
    target_tier in tier_def.can_orchestrate
  end
end

Agent Lifecycle Management

Agents follow a defined lifecycle from creation through retirement:

Phase	Description	OTP Mapping	Telemetry Event
Registration	Agent declared in AIAD registry	Module compilation	`[:agent, :registered]`
Initialization	Process started, state loaded	`GenServer.init/1`	`[:agent, :started]`
Idle	Awaiting tasks, monitoring conditions	`handle_info` loop	`[:agent, :idle]`
Perceiving	Gathering environmental data	Custom callback	`[:agent, :perceiving]`
Reasoning	Analyzing percepts, forming decisions	Custom callback	`[:agent, :reasoning]`
Acting	Executing decided actions	Custom callback	`[:agent, :acting]`
Error	Handling failures, potential restart	Supervisor restart	`[:agent, :error]`
Termination	Graceful shutdown, state persistence	`terminate/2`	`[:agent, :stopped]`

Implementation in Prismatic Platform

Scale and Scope

The platform operates 530+ AI agents across 16 domains:

Domain	Agent Count	Key Agents	Primary Function
Security (Color Team)	20	Red/Blue/Purple/White/Gray/Black teams	Epistemic security through adversarial-defensive synthesis
Quality	45+	Autoevolve, Autoheal, Quality Guardian	Autonomous quality monitoring and improvement
OSINT	120+	Czech adapters, Global providers, Sanctions	Open source intelligence gathering
Platform Operations	50+	Session Lifecycle, Supervisor, Health Monitor	Infrastructure management
Content Enhancement	30+	Promo Content Enhancer, Documentation agents	Content quality and consistency
Compliance	25+	NIS2, ZKB assessors, Audit agents	Regulatory compliance assessment
Other Domains	240+	Various specialist and utility agents	Domain-specific operations

AIAD Standard Compliance

Every AI agent in the platform adheres to the AIAD standard, which mandates:

Declarative Specification -- Agent capabilities, constraints, and protocols defined in YAML
NO MERCY, NO DOUBTS Enforcement -- All agents comply with the platform doctrine
Trinity Gate Passage -- Agent outputs pass structural, logical, and formal verification
NABLA Axiom Compliance -- Agents maintain signal plurality and contradiction preservation
Telemetry Instrumentation -- All agent lifecycle events emit telemetry for observability

Agent Communication Example

A complete example of two agents collaborating through the platform's protocol:

# Red Team agent discovers a vulnerability
{:ok, finding} = PrismaticAgents.Agent.execute(
  {:via, Registry, {:agents, "red-epistemic-attacker"}},
  %{
    action: :simulate_attack,
    target: "authentication_module",
    technique: :confidence_manipulation,
    parameters: %{intensity: :medium}
  }
)

# Finding is routed to Purple Team for synthesis
{:ok, synthesis} = PrismaticAgents.Agent.execute(
  {:via, Registry, {:agents, "purple-coordinator"}},
  %{
    action: :synthesize_finding,
    source: "red-epistemic-attacker",
    finding: finding,
    context: %{campaign_id: "sec-2026-042"}
  }
)

# Synthesis triggers Blue Team defensive response
{:ok, defense} = PrismaticAgents.Agent.execute(
  {:via, Registry, {:agents, "blue-commander"}},
  %{
    action: :update_defensive_posture,
    synthesis: synthesis,
    priority: :high
  }
)

Comparison with Alternatives

Framework	Language	Agent Model	Fault Tolerance	Scalability	Maturity
Prismatic AIAD	Elixir/OTP	Process-per-agent, supervision trees	Excellent (OTP)	530+ agents production	Production (Gen 19)
LangChain	Python/JS	Chain composition, tool use	Limited (try/except)	Stateless	Mature ecosystem
AutoGen	Python	Conversational agents	Conversation-level	Session-based	Active development
CrewAI	Python	Role-based teams	Task-level retry	Sequential/parallel	Growing
Semantic Kernel	C#/Python	Plugin-based agents	.NET exception handling	Azure-scale	Microsoft-backed
Haystack	Python	Pipeline-based	Component-level	Horizontal	Production
Custom (bare metal)	Any	Application-specific	Application-specific	Application-specific	Depends

The Prismatic Platform's approach is distinguished by its use of the BEAM virtual machine, which provides lightweight process isolation (millions of concurrent agents), preemptive scheduling (fair CPU allocation), soft real-time guarantees, and battle-tested fault tolerance through OTP supervision. No other AI agent framework provides this level of infrastructure maturity for concurrent agent systems.

Best Practices

1. Define Clear Agent Boundaries

Each agent should have a single, well-defined responsibility. Avoid creating "god agents" that handle multiple unrelated concerns. The AIAD standard enforces this through explicit capability declarations.

2. Design for Composition, Not Monoliths

Complex behaviors should emerge from the orchestrated composition of simple, focused agents. A security assessment is not one monolithic agent but a pipeline of specialized agents coordinated by an orchestrator.

3. Implement Graceful Degradation

Agents should handle failures gracefully, returning structured {:error, reason} tuples rather than crashing unexpectedly. When an agent cannot complete a task, it should communicate what it achieved and what failed.

4. Use the Appropriate Tier

Not every agent needs L1 strategic authority. Most agents operate effectively at L4 (Specialist) or L5 (Autonomous). Over-privileged agents increase risk without benefit.

5. Instrument Everything

Every agent action should emit telemetry events. This enables monitoring, debugging, and performance optimization across the agent fleet.

6. Test Agent Behavior, Not Just Code

Unit tests verify code correctness, but agent testing must also verify behavioral properties: does the agent achieve its goals? Does it handle unexpected inputs gracefully? Does it respect its authority constraints?

Common Pitfalls

Anthropomorphizing Agents

AI agents are software processes, not people. Attributing human-like understanding, motivation, or judgment to agents leads to over-trust and under-testing. Every agent decision must be verifiable and auditable.

Unbounded Autonomy

Agents without clear operational constraints can take unexpected actions with severe consequences. The tier system and approval requirements exist to bound autonomy appropriately.

Ignoring Agent Interaction Effects

Individual agents may behave correctly but produce emergent problems when interacting. Test multi-agent scenarios, not just individual agent behavior. The Color Team exercises specifically test interaction effects.

State Accumulation Without Cleanup

Long-running agents that accumulate state without cleanup eventually exhaust memory. Implement state rotation, history truncation, and periodic world model pruning.

Tight Coupling to Specific LLM Providers

Agents tightly coupled to a specific LLM API become fragile when APIs change or providers experience outages. The platform abstracts LLM access behind a provider-agnostic interface with automatic fallback to Ollama local models.

Use Cases

Autonomous Security Operations

The 20-agent Color Team conducts continuous security assessment: Gray Team discovers boundary conditions, Red Team simulates attacks, Blue Team maintains defenses, Purple Team synthesizes findings, White Team proves invariants, and Black Team models theoretical threats.

Intelligent OSINT Gathering

120+ OSINT agents gather intelligence from global data sources, correlating information across Czech business registries, sanctions lists, domain intelligence providers, and social media analysis tools.

Continuous Quality Improvement

Quality agents (autoevolve, autoheal) monitor codebase health, identify quality debt, generate fixes, verify corrections, and report results -- maintaining the platform's 100/100 quality score autonomously.

Compliance Monitoring

Compliance agents continuously assess the platform against NIS2 and ZKB regulatory requirements, generating evidence documentation and flagging non-conformities for human review.

Content Generation and Enhancement

Content agents analyze documentation quality, identify gaps, generate enhancement suggestions, and verify cross-references across the platform's 1,800+ documentation pages.

Agent - The general software agent concept that AI agents extend with artificial intelligence capabilities
AIAD - The AI Agent Definition standard governing all agent specifications in the platform
Autonomous Agent - Agents with maximum independence in decision-making and action
LLM - Large language models that power modern AI agent reasoning capabilities
Agent Tier - The five-level authority hierarchy organizing agent permissions and autonomy
Agent Orchestration - Coordination of multiple AI agents for complex collaborative tasks
Multi-Agent System - Theoretical framework for systems of interacting autonomous agents
GenServer - The OTP behaviour that implements agent processes in Elixir
Agent Registry - Discovery and lookup service for finding available agents
Agent Pool - Dynamic pool of agent processes for load-balanced task execution

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

GitHub | GitLab | LinkedIn | Contact
Developer Portal | Architecture | Meet the Creator

AI Agent

Definition

Overview

Agent Classification

The AIAD Agent Anatomy

Technical Details

Agent Architecture

LLM-Powered Agent Implementation

Agent Tier System

Agent Lifecycle Management

Implementation in Prismatic Platform

Scale and Scope

AIAD Standard Compliance

Agent Communication Example

Comparison with Alternatives

Best Practices

1. Define Clear Agent Boundaries

2. Design for Composition, Not Monoliths

3. Implement Graceful Degradation

4. Use the Appropriate Tier

5. Instrument Everything

6. Test Agent Behavior, Not Just Code

Common Pitfalls

Anthropomorphizing Agents

Unbounded Autonomy

Ignoring Agent Interaction Effects

State Accumulation Without Cleanup

Tight Coupling to Specific LLM Providers

Use Cases

Autonomous Security Operations

Intelligent OSINT Gathering

Continuous Quality Improvement

Compliance Monitoring

Content Generation and Enhancement

See Also

Connect & Contribute

Glossary

Related Terms

AI Agent

Definition

Overview

Agent Classification

The AIAD Agent Anatomy

Technical Details

Agent Architecture

LLM-Powered Agent Implementation

Agent Tier System

Agent Lifecycle Management

Implementation in Prismatic Platform

Scale and Scope

AIAD Standard Compliance

Agent Communication Example

Comparison with Alternatives

Best Practices

1. Define Clear Agent Boundaries

2. Design for Composition, Not Monoliths

3. Implement Graceful Degradation

4. Use the Appropriate Tier

5. Instrument Everything

6. Test Agent Behavior, Not Just Code

Common Pitfalls

Anthropomorphizing Agents

Unbounded Autonomy

Ignoring Agent Interaction Effects

State Accumulation Without Cleanup

Tight Coupling to Specific LLM Providers

Use Cases

Autonomous Security Operations

Intelligent OSINT Gathering

Continuous Quality Improvement

Compliance Monitoring

Content Generation and Enhancement

Related Concepts

See Also

Connect & Contribute

Glossary

Related Terms