Skip to content
Squad AI

Executing Workflows

When AIM decides to execute a workflow, it doesn’t interpret a static script. It reads a workflow graph from the knowledge graph and renders it into an executable workflow at runtime. This approach means workflows are data: they can be inspected, versioned, taught, and evolved: while execution remains dynamic and context-aware.

The GraphBuilder

The GraphBuilder is the bridge between stored knowledge and live execution. It reads a workflow definition from the knowledge graph: a Workflow node connected to ordered Steps, each referencing the Tools they use: and compiles it into an executable directed acyclic graph (DAG) at runtime.

GraphBuilder Flow
Knowledge Graph GraphBuilder Plan Step 1 Step 2 Step 3 Tool A Tool B Tool C Executable Workflow reads renders HAS_STEP FIRST_STEP NEXT_STEP NEXT_STEP USES_TOOL USES_TOOL USES_TOOL

At render time, the GraphBuilder resolves each step’s tool implementation, loads any few-shot examples or prompt masks associated with the step, and wires the steps into a sequential (or conditionally branching) execution graph. The result is a workflow that’s ready to run: with every step knowing exactly what tool to call and how to call it.

Dynamic Tool Resolution

Tools are registered in the knowledge graph with metadata: name, description, parameter schema, and a reference to their implementation. The Dynamic Tool Loader resolves implementations at runtime, meaning newly created and approved tools are immediately available to any workflow that references them. No redeployment needed.

This closes a powerful loop: the Explorer identifies a capability gap, tool creation generates a new tool, a human approves it, and the GraphBuilder can use it in the very next workflow invocation.

Three Step Types

Each step in a workflow carries a type that determines how it executes. This is where Squad’s dual-process model becomes concrete:

Deterministic Tool Calls: System 1

The simplest and fastest step type. A function is called with specific arguments and returns a result. No AI model is involved: the step is purely deterministic.

Examples: Validating file formats, filtering data, executing a database query, writing structured output.

These steps are fast, cheap, and fully predictable. They represent the majority of steps in a mature, hardened workflow.

Masked LLM Calls: System 1

An AI model is used, but as a reflex: constrained by a specific prompt template and few-shot examples stored on the step. The model has no autonomy; it receives a tightly scoped instruction and returns a structured response.

Examples: Classifying items into categories, summarising a document section, extracting structured fields from text.

Despite using an AI model, these are System 1 operations: the prompt mask ensures consistent, predictable behaviour. The model acts as a pattern matcher, not a reasoner.

Boxed Agent Loops: System 2

The most powerful and expensive step type. A scoped AIM agent loop runs within the step: planning, executing sub-steps, and reviewing results within a bounded context. The agent has access to tools and can reason, but is constrained by the step’s mask and scope.

Examples: Exploring an unfamiliar data source, answering a sub-question that requires multi-hop reasoning, handling an edge case that doesn’t fit a template.

These steps represent genuine deliberation. They’re slower and more expensive, but they handle the cases that deterministic steps and masked calls cannot.

Progressive Hardening

Progressive hardening describes how step execution can become cheaper and more constrained over time. As patterns prove reliable (and where governance allows), System 2 steps that produce repeatable results can be demoted to System 1:

Progressive Hardening
System 2 / Boxed Agent Loop (slow, expensive) Extract effective prompt + few-shot examples System 1 / Masked LLM Call (fast, constrained) Extract deterministic logic System 1 / Deterministic Tool (fastest, cheapest)
  1. A novel task starts as a boxed agent loop: AIM reasons through it step by step.
  2. After repeated success, the effective prompt and examples are extracted, and the step becomes a masked LLM call: same output, but constrained and faster.
  3. If the pattern is fully deterministic, it can be further hardened into a tool call: no AI model needed at all.

Each demotion makes the workflow faster and cheaper without sacrificing quality. The workflow graph in the knowledge graph is updated to reflect the new step type, so future executions automatically benefit.

Execution in Practice

Step-by-Step Processing

The executor processes steps sequentially, recording the result of each step before advancing to the next. Every tool call is logged with its inputs, outputs, duration, and success status: creating a complete audit trail.

Conditional Branching

Steps can carry conditions on their connections: allowing workflows to branch based on intermediate results. For example, a step might check whether a service is available and route to different tool implementations accordingly.

Review at Every Step

After each step, the reviewer validates the result against quality and security criteria. Failed steps are fed back to the planner with context, allowing mid-workflow replanning rather than full failure.