AgentSphere: A Co-World Space for Multi AI Models on GreenNode AgentBase

Small and medium open-source models don't need to be orchestrated like a fixed assembly line. Give them a shared world, a common memory, a common contract, a planner that decides who speaks next, and a 27B model pool starts solving work that used to require a frontier API.

The problem with one big model doing everything

A production agent rarely does one thing. It reads a question, pulls documents, normalizes what it found, reasons over it, calls a tool, then checks its own work. Sending all six of those steps to a single frontier model is simple to build and expensive to run: you pay flagship prices for steps that a 14B model finishes correctly, and you pay them again on every retry.

The obvious fix  (“use a smaller model”) fails for a different reason. Small models are good at narrow steps and bad at holding a long, messy task in their head. What they lack is not intelligence per step; it is shared state. Each call starts from nothing, so context has to be re-sent, re-explained, and re-derived.

You can see the cost of that missing state in a trace. A six-step research task on a single frontier model re-sends the same retrieved passages three or four times, once per reasoning turn, because the only way to carry a fact forward is to put it back in the prompt. Input tokens balloon, latency grows with them, and every retry pays the whole bill again from the top.

AgentSphere is our answer to that: a co-world space where several small and medium open-source models work on the same task, in the same memory, under one planner, running inside your own VPC on GreenNode AgentBase. The models stay stateless and interchangeable; the task keeps its state outside them.

The short version

Agents are roles, not models. A planner picks the next capability from the state of a shared context bus and binds a model to it at that moment. Simple steps land on a Small model, hard steps on Medium, rejected steps escalate, and on a 1B-token month of deep research that arithmetic comes out roughly 11× cheaper than GPT-5.1.

What “co-world space” actually means

Three properties, and all three have to hold at once. Break any one of them and you are back to a pipeline of isolated API calls. Drop the shared memory and every handoff becomes a re-send. Drop the schema and a payload written by one model becomes unreadable to the next. Drop the planner and you have hard-coded a flow that only fits the task you happened to test.

• One memory: every step writes to and reads from the same store. No model owns context; no handoff loses it.
• One contract: payloads are plain JSON against a schema, never KV-cache or model-specific state. Any model can consume any entry.
• No fixed flow: the planner re-plans after every write. A simple task takes one step; a hard one loops until the verifier accepts.

Models don't call each other, they share a bus

There is no agent-to-agent RPC in AgentSphere. A step writes its result to the shared context bus under a named key; the planner reads the new state and decides what runs next; the next step reads what it needs. That indirection is what makes the model binding free: because nothing in the payload is tied to the producer, the same findings entry is equally readable whether MiniMax-M2.5 or Qwen3.6 wrote it.

Two layers sit behind the bus. Short-term is the working set for the session, turn history plus every bus write, compacted into a summary when it outgrows the budget. Long-term is the distilled residue: deduplicated facts with provenance, recalled semantically by any model in a later session. AgentBase's Memory service provides both, so the models stay stateless while the task does not.

Context assembly is where the model size stops mattering. Before a step runs, the runtime builds its prompt from four parts, the task spec, the bus entries that step declares it needs, the top-k long-term facts for the current query, and the compacted history, then trims to that model's budget. A Small model gets a ranked subset; a Medium model gets the full working set. Neither one sees a raw transcript, so a 14B model is not being asked to do a 200K-token job in the first place.

Two rules keep the shared state honest. Every write carries provenance — step id, capability, model — so a wrong answer is traceable to the step that produced it, and the verifier can invalidate exactly that fact rather than the whole run. And on conflict, the newest write wins unless verification says otherwise, which is what lets a re-run overwrite a rejected step cleanly instead of leaving two contradictory facts in memory.

Setting up a squad

Configuration is deliberately shallow: name an agent, give it a role, pick a model from the ones enabled on your GreenNode MaaS account, and optionally write a standing mandate — a rule that stays in force for every phase, like “only trust official VN sources; always flag legal risk”. The lead orchestrator splits a mission into phases and synthesizes findings; the workers take whatever focus the lead assigns and ground every claim.

Because the bus is model-agnostic, the model dropdown is the cheapest thing in the system to change. Swap a worker from Gemma 4 31B to MiniMax-M2.5 and nothing else in the squad needs to know — same keys, same schema, same memory.

Two workloads, and what they cost

Architecture arguments are cheap; token bills are not. Below are the two workloads we see most often on AgentBase, modelled from 500K tokens (a pilot week) to 1B tokens (a busy production month), against GPT-5.1 at list price.

Use case A · Deep research

Multi-source investigation with retrieve ⇄ reason loops and a verification pass. ~250K tokens per task, 80% input / 20% output. Routing mix 55% Small · 45% Medium; 1B tokens ≈ 4,000 research tasks.

Use case B · Internal knowledgebase retrieval

RAG over internal documents with citations and a short grounded answer. ~12K tokens per query, 90% input / 10% output. Routing mix 85% Small · 15% Medium; 1B tokens ≈ 83,000 queries.

Blended cost per 1M tokens

• Deep research · GPT-5.1: $3.00 per 1M tokens
• Deep research · AgentSphere: $0.26 per 1M tokens - 11.6× cheaper
• KB retrieval · GPT-5.1: $2.13 per 1M tokens
• KB retrieval · AgentSphere: $0.16 per 1M tokens — 13.5× cheaper

How the numbers were computed

• GPT-5.1 list price: $1.25 per 1M input tokens, $10.00 per 1M output tokens.
• AgentSphere model pool (illustrative MaaS rates): Small ≈ $0.10 / $0.40 and Medium ≈ $0.25 / $0.90 per 1M input / output. Substitute your contracted GreenNode MaaS rate: the ratio, not the absolute, is the point.
• Routing mix already includes escalation retries; a rejected step re-running on a larger model is counted in the Medium share.
• Fair-play note: with 50% of input served from GPT-5.1 prompt caching, the deep-research bill drops to about $2,550 per 1B tokens: still roughly 10× the AgentSphere figure, because caching discounts input while output stays at $10 / 1M.
• Not included: AgentBase Runtime, vDB and vStorage. These are fixed monthly infrastructure and do not scale with token volume.

Where the savings actually come from

Not from the model being cheap, from most steps not needing an expensive model. In a deep-research run, the token mass sits in retrieval and extraction: reading passages, normalizing them into records, checking citations. Those are schema-bound steps where a 14B model with a good prompt is indistinguishable from a frontier one. Reasoning and final synthesis get Medium. Verification is cheap but decisive: when it rejects, only that step re-runs, against a bus that already holds everything gathered so far.

That last point is the quiet cost lever. In a stateless pipeline, a failed step means replaying the conversation. In a co-world space, it means re-running one step and paying for one step.

There is a second, less obvious saving in the input column. Because facts live in memory instead of the prompt, a retrieved passage is read once, distilled once, and referenced by key afterwards. The deep-research mix above assumes 80% input precisely because that ratio holds when you stop re-sending context; on a single-model pipeline the same task drifts closer to 90% input, and the extra tokens land at flagship rates.

Start conservative and let Langfuse move the dial. Run everything on Medium for a week, look at which capabilities the verifier never rejects, and demote those to Small one at a time. In our own runs the routing mix stabilised near 55/45 for research and 85/15 for retrieval, but that mix is a property of your documents and prompts, not a constant, and it is the single number that decides the bill.

What it runs on

When not to use it

A co-world space earns its keep when a task has several distinguishable steps and enough volume for routing to matter. For a single-shot chat completion, the planner overhead buys you nothing — call one model. For frontier-hard reasoning that no open 30B model reaches, route that step out to a frontier API and keep the rest of the run in the pool; the bus does not care where a payload came from, and that is precisely the point.

Build your own co-world space

Start with two capabilities and one shared memory store on AgentBase, add models to the pool as the routing data tells you to.

Memory docs: https://docs.greennode.ai/ai-stack/agent-base/memory