Concepts

A handful of ideas explain most of how loomflow behaves: what an agent is made of, how runs and conversations relate, what memory stores, and how one agent serves many users safely. Each page below takes a few minutes.

What is an AgentInstructions, a model, and the parts you plug in (tools, memory, limits), driven by a loop.Run vs Session vs RunContextA run is one call. A session is a conversation across many calls. RunContext tells your tools which run they’re in.Episode vs FactEpisodes are what was said. Facts are short claims pulled out of it, like “alice lives in Tokyo”.Tools vs Skills vs ToolHostA tool is a function the model can call. A skill is a set of instructions it loads when needed. A ToolHost holds the tools.Multi-tenancyHow passing user_id keeps each user’s memory, budget, permissions and audit records apart.

How the pieces fit

An agent is a loop (the architecture) plus the components it uses. Every component has a default, so Agent("...", model="...") works on its own, and each one can be swapped for another implementation, or your own, without changing the rest.

Five ideas behind the design

Swap any part. Each component is defined by a small interface (a Python Protocol). To use a different memory store or model provider, pass any object with the right methods; you never subclass the framework.
user_id goes everywhere. Pass it once to agent.run() and memory, budgets, the audit log and your tools all see it.
You only pay for what you use. Unset components are no-ops (allow-all permissions, no telemetry, no audit log), and the loop skips them entirely.
The loop is a setting. ReAct is the default; architecture= picks another loop style without changing anything else.
Loops nest. An architecture can wrap another one, so a team of agents can itself reflect and retry, using the same Agent class.

Where to next

Build: the Quickstart, then the Production tour.
Pick a loop: Architectures compares all twelve.
Look under the hood: How it works follows one run step by step.