MeTTa + PeTTa + Prolog: How They Connect

When each language activates and how data flows between them

Agent Loop (every cycle)LLM emits tool commands (metta (|- ...))(shell sh run.sh x.metta) PATH A: MeTTa Inline EngineRuns EVERY cycle when agent calls (metta ...) NAL Inference: |- operatorDeduction, revision, analogyPLN Inference: |~ operatorAbduction, implication Returns (stv strength confidence)Direct to agent, same process PATH B: Shell to PeTTaOnly when agent runs sh run.sh run.sh (Bash wrapper)Passes .metta file to swipl SWI-Prolog (swipl)--stack_limit=8g -q -s main.plProlog is the actual runtime engine PeTTa: MeTTa-in-PrologParses MeTTa syntax into Prolog termsKB queries + arithmetic work NO |- or |~ operatorsInference must use inline metta Results return to Agent Loop

What is this diagram? This shows the two separate paths the agent uses to interact with MeTTa-family languages. They look similar but work completely differently under the hood. Understanding this split is key to understanding why the system behaves the way it does.

Path A — Inline MeTTa (the fast lane): When the agent needs to reason — combine two pieces of evidence, check if a conclusion follows from premises, or estimate how likely something is — it calls (metta (|- ...)) or (metta (|~ ...)) directly. This happens inside the same process, with no file I/O. The embedded MeTTa engine performs Non-Axiomatic Logic (NAL) or Probabilistic Logic Networks (PLN) inference and returns a truth value like (stv 0.85 0.9) meaning 85% strength with 90% confidence. This path activates on most cycles.

Path B — PeTTa via Prolog (the heavy lifter): When the agent needs to run a full MeTTa program with multiple function definitions, persistent facts, or arithmetic — things that require state across multiple expressions — it writes a .metta file and runs (shell sh run.sh file.metta). The run.sh script invokes SWI-Prolog (swipl), which loads PeTTa: a complete reimplementation of MeTTa syntax on top of Prolog. Prolog is the actual execution engine here. This path only activates when explicitly called.

The critical difference: PeTTa can store knowledge, define functions, and do arithmetic — but it does not have the |- or |~ inference operators. Those only exist in Path A. So if the agent wants to reason about uncertain knowledge stored in a PeTTa program, it must extract the relevant facts and feed them back through inline MeTTa. This is why both paths coexist: they each handle what the other cannot.

The execution chain in detail: Agent emits shell command → Bash runs run.sh → run.sh calls swipl with --stack_limit=8g -q -s main.pl → Prolog loads the PeTTa translator modules → PeTTa parses .metta syntax into Prolog terms → Prolog evaluates those terms → results print to stdout → stdout returns to agent. Each step is a real process boundary.

Why not just use one? Inline MeTTa is stateless — each call is independent with no memory of previous calls. PeTTa via Prolog can maintain state within a file execution but lacks reasoning operators. The agent learned through trial and error that some tasks need inference (Path A) and others need stateful programs (Path B). This dual architecture was discovered empirically, not designed.