Multi-agent framework: one data connection for all agents

When people search for a multi-agent framework, they want to know how to run several agents that work together: one plans, one researches, one writes, one checks. Many frameworks exist, in Python and in TypeScript, and the choice feels big.

I think the choice is smaller than it looks, and I think a different question gets less attention: how do those agents reach data? A research agent that cannot search, or a sales agent that cannot look up a company, is only a prompt. This post separates the two questions and shows a way to give every agent in any framework the same data tools.

What does a multi-agent framework do?

A multi-agent framework manages control flow between agents. It decides who runs when, how messages pass, how state is shared and when the run ends. Some frameworks organize agents as roles in a team. Others as nodes in a graph. Others as a chat among agents.

That is the whole job. A framework does not know how to find a company's email or read a Google result. It leaves tools to you, which means each agent in your system needs tools defined and wired in.

How do I choose a framework?

Choose by what the control flow needs, not by the data you want. Ask four questions.

1. Is the flow fixed, or does an agent decide the next step? Fixed flows suit a graph. Open-ended flows suit a chat or a planner.
2. Which language does your team write? Python and TypeScript both have options, and a framework you cannot read is a risk.
3. Do you need to pause for a human to approve a step? Check that the framework supports it, and test it.
4. How will you debug a failed run? Look at what each framework logs and whether you can replay a run.

I will not rank frameworks here. I have not run each of them against the same job, and a ranking built on reading their READMEs would be noise. Run your own small job on two of them before you commit.

Why does data access cause the real trouble?

With one agent, tools are a short list. With five agents, three problems appear.

Duplicated keys. Each agent that needs search gets a key or shares one. Keys end up in several config files, and a leak is harder to trace.

No shared cost record. Agent A and agent B both call the same enrichment API. Which one spent what? With separate integrations, nobody can say until the invoice arrives.

Inconsistent tools. The researcher uses one search provider and the writer uses another, so they disagree on what the web says. A shared connection makes the agents see the same tools.

A fourth problem is spend. Five agents can make five times the calls, and a loop in one of them can run up cost. You need a limit that applies to the whole system, not just to one agent.

How do I give all agents the same data tools?

Put the tools behind one connection and give each agent access to it. Any framework that can connect to an MCP server or call a REST API can do this, and most can do one or the other. What is an MCP server explains the protocol.

With looot, each agent holds a token. Every agent has the same small set of tools: discover, inspect, run, runs, balance and top_up. They find endpoints by describing a job, so the researcher and the writer can use the same search endpoint. The runs tool shows what ran and what each run cost, which answers the "who spent what" question from one place.

AI agent tools for data and APIs maps the jobs agents call tools for, and MCP gateway for agents explains when a gateway is worth it.

What does a team of agents cost to run?

The framework itself adds no data cost. The cost comes from the model tokens each agent uses and the tool calls each one makes. For tool calls, read the price of the endpoints your agents will use and multiply by the number of calls you expect.

Put the limit in the shared instruction: a maximum number of calls per task and a stop when the balance passes a threshold you set. The balance tool lets any agent read what is left.

How should agents share what they find?

Pass results, not raw tool output. If the researcher fetched ten pages, the writer does not need ten pages. It needs a short summary with source links. Frameworks differ in how they pass state, so check yours, but the principle is the same: each hand-off should be the smallest thing the next agent needs.

A shared store helps. If the researcher writes findings to a table or a file and the writer reads from it, nobody has to re-run a search. That saves calls, and calls cost money. Ask each agent to check the shared store first and call a data endpoint only when the answer is not there.

How do I debug a run that spans several agents?

Start from the cost record, because it shows what actually ran. The runs tool lists each call with its endpoint and cost. Read it in order and match each call to the agent that made it. You will usually find the problem in one of three places: an agent called an endpoint with a wrong input, two agents made the same call, or one agent looped.

Duplicate calls are the easiest to fix. Add a line to the shared instruction: before you call an endpoint, check whether another agent already stored the answer. Loops need a call limit per agent. And a wrong input needs a better tool description or a validation step before the call.

Try it: a prompt for your agent

This prompt works in a single agent and in each agent of a team. It checks that an agent can see the shared tools and prices without spending anything.

Run it once per agent. If every agent returns the same endpoints and prices, they share the same view.

What it cannot do

• It is not a framework. looot does not manage agent control flow, memory or messages between agents.
• It does not stop a loop inside an agent. Put call limits in the instructions.
• It does not give every agent different permissions on its own. Each agent that holds the same token has the same access.
• It does not schedule agents. A team that must start on its own needs scheduled runs, not available yet.

Last checked 2026-10-03 against the live catalog and the looot skill file. Author: Walid.