Building AI Agents with Prolog

AI agents that reason, plan, and act autonomously are a major focus of modern AI research. Prolog’s built-in support for logical reasoning, backtracking search, and knowledge representation makes it an excellent foundation for building intelligent agents.

An AI agent is a system that perceives its environment, reasons about what it observes, and takes actions to achieve its goals. Every agent, from a simple thermostat to a LLM-powered research assistant, follows the same fundamental pattern: the perception-reasoning-action loop.

1. Perceive: observe the environment. This could mean reading sensor data, parsing a user’s natural language query, checking a database, or fetching the contents of a web page.
2. Reason: decide what to do next. The agent matches its observations against its goals and its knowledge of how the world works, then selects the best action.
3. Act: carry out the chosen action and feed the outcome back into the loop.

Prolog is a natural fit for agent architectures because its inference engine already implements a reasoning loop: given a goal, Prolog searches for a proof using the available rules and facts. Wrapping that inference engine inside a perception-action cycle produces a goal-directed agent with minimal code.

A reactive agent responds directly to its current perceptions without maintaining an internal model of the world. It maps observations to actions using simple rules. While limited, a reactive agent is fast, predictable, and easy to debug — making it the right starting point before adding the complexity of planning, memory, or tool use.

The reactive_agent project implements a reusable reactive agent framework with a perception-reasoning-action loop. Here is the file reactive_agent/prolog/agent.pl:

The module defines four dynamic predicates as the agent’s working memory: goal/1 stores the current objective, tool/2 registers named actions the agent can take, belief/1 holds facts the agent has learned, and action_log/2 records every action with its timestamp for later analysis.

The core of the framework is run_agent/1. It takes a maximum step count and enters a loop: check whether the goal is already satisfied (in which case stop), then perceive the environment, select an action, execute it, decrement the counter, and recurse. The base case fires when the step counter reaches zero, preventing infinite loops.

The three predicates perceive/0, select_action/1, and execute_action/1 are deliberately written as extension points. Out of the box, perceive/0 does nothing, select_action/1 falls back to idle, and execute_action/1 logs the action with a timestamp. To build a working agent for a specific domain, you override these predicates in a separate module that imports agent.

Suppose we want an agent that monitors a file system and responds to disk space warnings. We create a new module that imports agent and fills in the extension points:

This demonstrates the pattern: perceive/0 populates belief/1 with observations, and select_action/1 matches beliefs against registered tools to pick the next step. The framework handles the loop, logging, and goal checking automatically.

Load the framework in SWI-Prolog and run:

The tests verify basic setup:

A reactive agent responds to the immediate situation. A goal-directed agent goes further: it maintains an explicit representation of what it wants to achieve and uses that goal to guide every decision. The distinction matters because the same observation — “the disk is at 5% free space” — might lead to different actions depending on whether the goal is keep_system_running or minimize_cost.

In our framework, goals are first-class. The goal/1 predicate stores the current objective, and run_agent/1 checks it at the top of every loop iteration. When goal(G), belief(G) succeeds, the agent stops — the goal is achieved. This pattern generalizes to multiple goals by extending the check:

Goal priorities are also straightforward to add. If goals conflict — say, save_disk_space and keep_logs_verbose — you order them with a priority argument:

Prolog’s unification engine makes goal matching natural: a goal like file_status(File, archived) succeeds when the belief database contains a matching belief(file_status('/var/log/syslog', archived)) fact. Variables in the goal term act as queries against the belief store.

The reactive agent pattern becomes far more capable when the agent can call external tools (web search, database queries, LLM APIs, file system operations) and when an LLM helps select which tool to use.

The architecture has three layers:

1. Tool Registry: Prolog facts (tool/2) mapping tool names to the predicates that implement them. Each tool is a Prolog predicate that the agent can call.
2. Action Selection: select_action/1 queries the tool registry and the belief store to find applicable actions. In a simple agent, this is pure Prolog rule matching. In an LLM-augmented agent, the agent sends the list of available tools and the current beliefs to an LLM and asks it to pick the next action.
3. Tool Execution: execute_action/1 calls the selected tool predicate and records the result as a new belief.

A richer select_action/1 that uses an LLM to choose among registered tools looks like this:

The LLM receives a description of the current state (beliefs) and a list of available tools, then returns the selected action as structured text. Prolog parses it back into a term and executes it. This combines the LLM’s flexibility (understanding natural language goals, adapting to novel situations) with Prolog’s reliability for tool execution and state management.

Tools are just Prolog predicates registered with register_tool/2:

Each tool predicate does its work and then asserts the result as a belief. This integrates the tool’s output into the agent’s state, making it available for the next round of reasoning and action selection.

When multiple agents operate in the same environment, they need to communicate, like sharing discoveries, delegating subtasks, and coordinating to avoid conflicting actions. Prolog’s dynamic database is inherently shared within a process, which makes message passing between agents as simple as asserting and querying facts.

A minimal message-passing system uses a message/3 dynamic predicate:

Each agent periodically calls receive_messages/2 in its perception step, processing messages and updating its beliefs accordingly. Because messages are retracted when read, each is consumed exactly once — a simple but effective protocol.

For more sophisticated coordination, agents can use a blackboard architecture: a shared data structure (the blackboard) to which any agent can post partial results or hypotheses. Other agents watch the blackboard for data relevant to their expertise. Prolog’s assert/retract mechanism implements a blackboard directly — agents assert findings as facts and other agents query those facts in their perception steps.

Each agent is a specialization of the same run_agent/1 loop, but with a different goal, tool set, and perception predicate. They run either interleaved in a single Prolog process or in separate threads using SWI-Prolog’s thread_create/2.

The research_assistant project sketches a multi-stage agent that answers research questions by chaining together web search, LLM summarization, and Prolog knowledge-base reasoning. Here is the file research_assistant/prolog/assistant.pl:

The pipeline is explicit in the code: research/2 chains five predicates, each handling one stage of the workflow. extract_search_terms/2 uses an LLM to pull key terms from the natural-language question. web_search/2 (a placeholder awaiting the Brave Search or Tavily API from the Web Clients chapter) fetches results. llm_summarize/2 condenses the raw search results into a digest. store_knowledge/3 asserts the summary into the knowledge/3 dynamic database, where other Prolog rules can reason over it. Finally, reason_over_knowledge/2 synthesizes an answer from the accumulated facts.

The placeholder web_search/2 is designed to be replaced with a real HTTP call to a search API. The Web Clients chapter covers http_get/3 and JSON parsing in detail. Once connected, the pipeline becomes fully operational:

The research assistant also benefits from caching: if the same question (or similar search terms) was answered recently, the agent can return the cached knowledge rather than repeating the full pipeline. This is a natural fit for the Cache Engine chapter’s patterns.

Running the assistant: