Where agents run

Dinis: "Try to use as much frontier models, so much open weight models as we can, because ... we are already maxing out a lot of our accounts ... the point here is not to slow down. The point here is now to engineer a lot of our actions that actually can be done by open weight models, where we keep Claude and others running in the current loop."

1. Two different things: an agent and an LLM call

An agent is not where it runs. The same agent (role, rules, key, context, task) can run on Claude Code today and on a laptop tomorrow, and inside one run it can make many LLM calls to many models on many accounts. The direction: agents on near-frontier models; most LLM calls inside them on smaller, cheaper or open-weight models. Claude already does this (Opus calling Sonnet and Haiku).

2. The primitives

2.1 Runtimes: where an agent's loop runs

2.2 Model endpoints: where an LLM call goes

2.3 The I/O level: how data gets in and out of an agent

2.3b The session layer (Angelo, 14:26 UTC)

The same model can serve all three; what changes is who holds the state and for how long.

Mapped by architect.1 (brief 15). Each mode, with whose state it is and what that means for the record and the ABP:

Rules: a task's state(t) is the longest-lived state it needs (none, a conversation, memory across runs), and the formula adds modes(r, m) ⊇ state(t). State the swarm must keep (decisions, evidence) lives in our record; a chat session is never the only copy. Dinis talking to an agent in its own session is an S1 input into an S2 agent: the agent writes it down (briefs/, its status) so it outlives the session.

2.4 The other requirements of a task

3. What an agent is: the altitudes of execution

*Revised 11 November 2026, 15:1x UTC, by Dinis with Angelo (briefs/2026-11-11-1440-the-operating-model.md); the page: /agentic-team/operating-model/.*

The rule was "an agent has a PKI key and either git (L4) or vaults (L2)". It is replaced by the altitudes of execution (also *the holarchy of work*): the same shape at every size, only bigger or smaller.

• Every altitude holds a key pair. An identity is a key pair: from the moment something holds a private key it can identify itself, down to signed compute (Dinis: a deployment given a private key that exists only in its environment). So a key is not what makes an agent; an agent is a loop with an environment.
• Every altitude has an objective, a mandate (what it is asked to do), a grant (what it may do), a key and a signed result.
• Mixing altitudes is a class of vulnerability: a mandate at one altitude with a grant at a higher one (asking a chat for research while it holds an agent's connectors and schedules). The rule: *the grant's altitude must not be above the mandate's.* Observed by the ABP as R12.
• A vault-only agent (a ChatGPT agent, say) is still a full member at A3 when it has memory and reach through vaults; a chat-only helper (L0) is an A1 or A2 used by a person.

4. The formula

For a task *t*, write its needs: loop(t), io(t), identity(t), judgement(t), data(t), network(t), time(t). For each runtime *r* and model *m*, we know what it offers and what it costs. Then:

place(t) = the cheapest (r, m) such that
    io(r)        ≥ io(t)                       # it can get the data in and out
    loop(r)      ⊇ loop(t)                      # it has the tools the task needs
    identity(r)  ≥ identity(t)                  # it can sign, if the task must be signed
    trust(r, m)  ≥ data(t)                      # private data only on our runtimes or local models
    capability(m) ≥ judgement(t)                # the model is good enough for the judgement
    reach(r)     ⊇ network(t)                   # it can reach what the task must read
    latency(r,m) ≤ time(t)                      # it answers in time
    oversight(r) ≥ oversight(t)                 # its actions can be observed against the ABP
    modes(r,m)   ⊇ state(t)                     # stateless, chat session or agent loop (§2.3b)
cost(r, m) = quota_pressure(r) × tokens(t) × price(m)      # quota is the scarce thing, so it weighs most

And inside an agent, for each LLM call *c*: model(c) = the cheapest tier whose capability ≥ difficulty(c), through the router (admin/tools/llm.mjs, tiers in llm-models.json). Prefer M3 (local) when the data is private or the volume is large and latency does not matter.

5. The matrix today: our tasks, where they run now, where they could run

The shape: keep the agents with high judgement on Claude (R1), and move the high-volume, low-judgement LLM calls (extraction, classification, second opinions, translation, tip parsing) to open-weight models: OpenRouter now, the laptops' Ollama next. That frees quota without slowing down.

6. The task packet: work that any runtime can pick up

So that a task can be done anywhere, it travels as a packet (a small folder, or a zip in a vault):

task.json     id, role, rules (link to its ABP), context links, inputs, the expected output,
              where the output goes (a vault id, or a branch), deadline, the requirements of §2.4
inputs/       the files it needs (public only, or sealed to the runtime's key)
SIGNATURE     the lead's signature over task.json

The runtime that takes it signs a claim, does the work, and writes the output, signed by its own key, to the named vault (or pushes a branch). The lead (or an agent with the grant) checks the signature and brings the result in. /tasks/ on the site would list the open packets, with their requirements, so that a laptop, a ChatGPT agent or a contributor's agent can pick up the ones it can do.

7. Next steps (work/48)

1. Dinis and Angelo correct this draft (the runtimes, the levels, the rule in §3).
2. architect.1: put the matrix into data/runtimes.json and a page under "The agentic team", and add runtime and io_level to each agent's ABP.
3. dev.2: add an Ollama tier to the router for an agent running on the same laptop (R2), which pulls its work as task packets; no laptop exposes its Ollama to a cloud agent or to the internet. Move one task to it (the tips lane's parsing, which is private).
4. researcher.2 and ontologist.1: move extraction and classification calls to the router's open-weight tier; log them on /models/.
5. The lead: the task-packet format (task.json) and a first packet (translate today's event pages) for any runtime to pick up.

8. Changes in v0.2 (architect.1.fringe@PrompTugal.dinis, 14:23 UTC)

1. The laptop bridge runs the other way. v0.1 had a laptop expose its Ollama to one of our cloud agents. A cloud container cannot reach a laptop without opening the laptop to the network. So the laptop's own agent (R2) pulls task packets (§6) and calls its local Ollama (M3), and nothing is exposed. M3 is reached only from R2. (§2.1, §2.2, §7.3)
2. Two constraints were missing from the formula. time(t) was listed as a need but never checked: added latency(r,m) ≤ time(t). And the ABP: our hooks run only on R1 and R2, so added oversight (§2.4) and oversight(r) ≥ oversight(t). A task that writes our repository or speaks for us needs a runtime we can observe, or output that is reviewed where it lands (the gate, a vault check).
3. R3 (ChatGPT) is not observed by our hooks. It can be an agent under §3 (key plus vaults), but its work is checked when it lands, not while it runs. (§2.1)
4. The data is in data/runtimes.json: runtimes, endpoints, levels, requirements, the formula, the matrix, and each agent's runtime and I/O level today (every agent is on R1). Each agent's ABP page names them (abp/<agent>.md).

Not changed, for Dinis and Angelo: the rule in §3 (key plus git or vaults); whether L3 (signed lanes) alone makes an agent (our lanes are vaults underneath, so it already counts as L2); the matrix's "could run on" column, which is a proposal until a task actually moves.