One request, a whole task: inside Mangrove

On 4 November we gave one of our test agents a small job: write today’s AI news digest, five items, each with a source.

Two minutes and twenty-two seconds later it had an answer. It had run eight web searches and tried to run a ninth, which was refused. It had tried six pages, and three of those websites blocked automated access. When it thought it was finished, a check sent it back to work. And at the bottom of its answer it said which two items rested on search results alone, because it never got to read the pages behind them.

The whole run used 1.96 Wh of energy.

That run is a good way to explain what Mangrove is, because almost everything that matters in it happened where you couldn’t see it.

Transcript

A chat model gives you one reply. Most work isn’t one reply. It’s search, read, compare, check, and often start again. Mangrove is GreenPT’s orchestration endpoint. You send one request. It works out what the task needs, uses the right tools, checks its own answer, and hands you the result. There’s no agent loop to build, and no tools to wire. Like the tree, it does its work below the surface.

A chat model gives you one reply

A chat completion is one question and one answer. Most work isn’t shaped like that. It’s search, read, compare, check, and quite often start again.

You can build that loop yourself. Plenty of teams do. You wire up tools, write a loop around the model, add a retry here and a limit there, and then you discover the expensive part: deciding what happens when a page is 1.3 million characters long, when the model says it’s done and isn’t, when every search fails and the model writes a polite apology that your system records as a success.

Mangrove is GreenPT’s orchestration endpoint. You send one request, and it carries the whole task through: it works out what the task needs, uses the right tools, checks its own answer and hands you the result.

curl -X POST https://api.greenpt.ai/v1/agents/runs \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{ "question": "Summarise the EU grid carbon intensity news from this week" }'

You get an agentId straight away. Then you poll the run, or stream its steps as they happen. There’s no agent loop to build and no tools to wire.

The name is literal. A mangrove does its work below the surface: the part you see is a tree, and the part that holds everything up is a network of roots reaching in every direction. That is how we think about orchestration. Above the surface, you see a task and a result.

One distinction before we go on, because it matters for everything below. Mangrove is not a model. It’s the system that runs one. The model that does the deciding has its own name.

Metis makes the call. Mangrove does the work.

Transcript

Before a run starts, three questions matter. How hard is this task? How much work is it? And how many sources does it need? A model that guesses spends too much, or too little. So Mangrove asks Metis, our decision model. Metis writes nothing. It reads the task once, and returns a probability for every possible answer. All three questions, in one pass. About sixty-five milliseconds of model time, and under five thousandths of a watt hour. Metis makes the call. Mangrove does the work.

Before a run starts, three questions matter. How hard is this task? How much work is it? How many sources does it need?

Get those wrong and you pay for it either way. An agent with no sense of scale spends a large model and a long budget on a one-line lookup, or gives a real research job too little room to finish.

So Mangrove asks Metis, our decision model. Metis doesn’t write. You give it a case and a set of questions, and it reads everything once and returns a probability for every possible answer. Mangrove sends all three questions in a single request.

Here is what came back for a real task on 5 November: “Summarise this week’s news on EU grid carbon intensity in five bullets, with a source for each.”

Question	Metis’s answer	The rest
How hard is it?	standard, 62%	complex 27%, simple 12%
How much work is it?	medium, 72%	long 15%, short 13%
How many sources?	several, 71%	many 14%, few 9%, none 6%

That decision took 63 ms of model time and 0.0041 Wh, and generated zero tokens. Those figures come from the impact report the API returns with the response.

Why not simply ask a chat model to classify the task? We tried that. In October we tested both for chat routing on 65 hand-labelled turns. Overall accuracy was close, 77% for Metis against 80% for a general model answering in JSON. The difference was in the mistakes and the wait. The general model took 2.3 seconds at the median and underestimated how much effort a turn needed 20% of the time. Metis answered three questions in about 230 ms and underestimated 2% of the time. An orchestrator asks this kind of question constantly, and an underestimate is the expensive mistake: the task gets too little room and fails. The probabilities help as well, because they are a number your logic can act on, with nothing to parse.

So that’s Metis’s place. Metis judges. Mangrove acts on the judgement. A language model reasons inside the run; Metis sets the terms of it from outside.

Right-sized work

Transcript

Not every task deserves the same effort. Ask for the capital of Finland, and Metis reads simple, and short. Ask for a table of every company on three stock indices, and it reads complex, and long. Those grades shape the run. Difficulty picks the model, so an easy job never wakes a large one. Length sets the limits on calls, tokens and time. Research depth sets how far it may look. A news digest gets eight searches, not seventeen. And if a grade doesn’t come back, the run keeps the limits it started with. Enough work, and no more.

Hard and long are different things. Finding the websites of 250 companies is simple per item and long in total. A subtle deadlock is the reverse. So Mangrove keeps the axes apart, and each one controls something different.

Difficulty picks the model. For a saved agent, a task graded simple goes to a smaller model and a complex one to a stronger one, so an easy job never wakes a large model. If you pin a model to your agent, your choice wins.

Length sets the limits. A task gets a budget of model calls, tokens and seconds that fits its size.

Research depth sets how far it may look. This one came out of a measurement. Before it existed, a five-item news digest took anywhere from 8 to 17 web searches and up to 9 page reads, all with different queries, because every search that found something invited another. A run had no sense of enough.

Research depth	Web searches	Page reads
None	1	1
Few	3	3
Several	8	6
Many	no cap	no cap

That’s the ninth search our digest had refused. The run is told its limit up front, and when it reaches it, the tool replies that the budget is spent and asks it to write up what it has. And Metis’s grades for very different tasks really are very different: “What is the capital of Finland?” came back simple (98%) and short (96%). A table of every listed company in the AEX, AMX and AScX came back complex (71%) and long (93%).

If a grade doesn’t come back at all, nothing breaks. A run that can’t be graded keeps the limits it started with. A failed classifier says nothing about the task, so it isn’t allowed to narrow anything.

Plan, then act

Transcript

A run doesn’t start by improvising. What’s certain comes first. A recording is transcribed, and an image is looked at, before the model ever sees your question. A task of more than one step gets a written plan, of at most eight steps, before any work begins. That plan is checked against the tools this run may use. If it can’t run, the task carries on without it. Then the agentic loop takes over: up to twenty rounds of calling tools and reading results, with a to-do list you can follow. Fixed steps for what’s certain. Judgement for what isn’t.

A run doesn’t start by improvising.

What’s certain comes first. If you send a recording, it’s transcribed before the model ever sees your question. If you send an image, it’s looked at first. The model never has to decide to do either, and it never has to repeat a multi-megabyte file back as tool arguments, which would be slow and costly, and one flipped character would corrupt it.

A task graded as more than a single step can then get a written plan of at most eight steps, generated before any work begins. We made that a separate call on purpose. A plan produced halfway through the work is a narration of what’s already happening; a plan produced first is a statement of intent you can check. It’s validated against the tools this run may use, and any step whose input depends on an earlier result is left to the model’s own judgement. If planning fails, or the task doesn’t break down into steps worth fixing in advance, the planner declines and the run continues as it would have without one.

Then the agentic loop takes over: up to twenty rounds of calling tools, reading results and deciding what’s next, with a to-do list you can follow in the stream.

Fixed steps for what’s certain. Judgement for what isn’t.

What it can reach

Transcript

An agent is only as useful as what it can reach. Mangrove searches the web and reads the pages it finds. It parses documents, looks at images, and transcribes meetings. It writes and runs Python in an isolated sandbox, for sums, charts, and Word, Excel and PowerPoint files. It saves values between runs, so the next one can compare. With your permission, it reaches your own work: Outlook, OneDrive, SharePoint, and any M C P server you connect. It can draft a reply in Outlook. It can never send one.

An agent is only as useful as what it can reach. Out of the box, Mangrove can:

• Search the web and read pages, keeping to the passages that matter for what it’s looking for.
• Parse documents, such as PDFs and Word files, from a link or an upload.
• Look at images directly, so charts and layout are seen as pictures rather than scraped as text.
• Transcribe meetings, then work from the transcript with speakers, decisions and action items.
• Run Python in an isolated sandbox, for sums, data analysis and charts, and to produce real Word, Excel, PowerPoint and PDF files.
• Save a value between runs under a name, so next week’s run can compare against this week’s.

With your permission, it also reaches your own work: search and read in Outlook, your files in OneDrive and SharePoint, and any MCP server you connect. It can save files back to OneDrive, and it can draft a reply in Outlook.

It can’t send one. There’s no send tool, and the endpoint behind the drafting tool can’t send either. A reply lands in your Drafts folder and waits for you. That’s a limit we built in on purpose, and we’d rather explain it than remove it.

It doesn’t get to decide it’s finished

Transcript

Most agents decide for themselves when they’re done. Mangrove doesn’t leave that to the model. Every plan ends with a check that no plan can remove. Does this fully answer the question? Would a tool you haven’t used close a gap? Going back to work counts. Only ticking off the to-do list doesn’t. And when a task can’t be done, the run says so. It ends as not done, with the reason, instead of an apology marked as success. If every tool it called has failed, the run ends as not done, however confident the answer sounds. An honest ending is part of the job.

This part of Mangrove comes from watching agents fail.

In a simple agent loop, the model decides when it’s done: it stops calling tools, and whatever it said last is the answer. Mangrove doesn’t leave that to the model. Every plan ends with a check, and no plan can remove it, because the runtime adds it after the plan is written.

The check asks whether the answer fully covers the question, and whether a tool the model hasn’t used could close a gap. The result isn’t self-reported. If the model goes back and calls a tool, that counts as work. If it only ticks off its to-do list, that doesn’t, because when we measured it, that is exactly what some models did: they marked every item complete and stopped.

In our digest run, the check sent the agent back for two more page reads. One was blocked. The other hit the page budget. The answer it then wrote said so.

Then there’s the failure mode nobody likes to talk about. Without a way to report failure, the only way to end a run is an answer. So a run that found nothing would end succeeded, on an apology, and its owner would be told it worked. We measured this on a real agent with every tool available: most runs whose every search failed still wrote an apology in the shape of a digest.

Mangrove gives the model a way out. It can end a run as not done, with a reason written for the person it’s for. And there’s a backstop for models that don’t take it: if a run called tools and every one of them failed, the run ends as task_not_done, however confident the answer sounds.

An honest ending is part of the job.

Limits that don’t depend on good behaviour

Transcript

An agent’s limits shouldn’t depend on its good behaviour. So Mangrove keeps them in the runtime, not in the prompt. A tool this run may not use is never shown to the model. If the model calls it anyway, the call is refused. Calls, tokens and time are counted across the whole run. And limits only tighten. A request can ask for less than the platform allows, never more. When the token budget runs out, the work isn’t thrown away. The run writes one closing answer, and names what it didn’t reach. You paid for the work, so you keep what it found.

You can ask a model nicely to stay within limits. It’s a poor way to run anything unattended, so Mangrove keeps its limits in the runtime.

A tool a run may not use is never shown to the model. If the model calls it anyway, the call is refused the same way an unknown tool is. Model calls, tokens and time are counted across the whole run, including the final check, so nothing can loop for free. By default a run gets 100 model calls, 1,000,000 tokens and 900 seconds, and a task’s own limits can sit lower: our digest ran with 60 calls, 600,000 tokens and 600 seconds.

Limits only tighten. A request can ask for less than the platform allows, never more.

Some details here took real incidents to learn. One scraped page of 1.3 million characters turned a 5,000-token conversation into a 347,000-token request, so every tool result is capped at 50,000 characters, and the model is told when one was cut. The token budget isn’t a fixed threshold either: it reserves room for a step as large as the largest one the run has already paid for, because the prompt grows with every result.

What happens at the limit may be the most useful part for anyone building agents. When the token budget runs out, the run doesn’t die. Discarding it would be the most expensive outcome there is, since you’d pay for every call and receive an error message. Instead it stops working and makes one closing call with no tools available, so it can’t start anything new, and it writes up what it has and names what it didn’t reach.

You paid for the work, so you keep what it found.

It acts for you, and only as you

Transcript

A run acts for you. So it may only ever act as you. Before it starts, a run takes on its owner’s identity, and checks that it’s the right one. If that check fails, the run doesn’t start. Saved values are tied to that owner. Mail and files are reached through references made for that one run. Tools from your connected servers are fenced off, and the run is told to treat what they return as data, not as orders. Python runs in its own isolated sandbox. Outlook can save a draft, with no way to send it. And each connection waits for your own switch. It can do a lot. It can only do it as you.

A run that can read your mail needs a clear answer to the question of whose mail it’s reading.

Before a run starts, it takes on its owner’s identity and checks that the identity it received matches the owner on the run. If it doesn’t match, the run doesn’t start. There’s no fallback account. The store for saved values has no field for whose data it means, so a tool call cannot address someone else’s. Mail and files are reached through references made for that one run, so the model handles a reference, not a mailbox.

Servers you connect over MCP are held at arm’s length. Their tool descriptions are fenced off, and the run is told that what they return is data, not orders. The worker running your agent never sees their addresses. Each connection, and each write permission such as saving drafts or files, waits for your own switch.

We won’t claim that makes a run impossible to mislead. An agent reads things written by strangers, and that risk doesn’t vanish because you’ve written a careful prompt. So we also limit what a misled run could do: it can’t send your mail, its code runs in isolation, and it can only use what you’ve connected.

A run that can wait for cleaner electricity

Transcript

Some work doesn’t have to happen right now. Add one field, and a run may start up to twenty-four hours late. Mangrove reads the grid forecast, and finds the cleanest start in that window. If waiting would save less than five percent, it starts straight away. If no forecast can be read, it starts straight away too. A carbon check never delays or fails a run. Either way, the response tells you what was decided, and by how much. The same work, at a cleaner hour.

This is the capability that says most about who built it.

Some work doesn’t have to happen right now. A weekly report can spare a few hours. Add one field, and a run may start up to 24 hours late:

{
  "question": "Summarise the EU grid carbon intensity news from this week",
  "greenShiftWindowHours": 8
}

Mangrove reads the carbon intensity forecast for the grid its models run on, and holds the run for the cleanest start in that window. It’s careful about when that’s worth it. If waiting would save less than 5%, the run starts straight away, because below that a delay costs you more than it saves the grid. If no forecast can be read, it starts straight away too. A carbon check never delays or fails a run.

The response tells you what was decided: held, run_now or unavailable, the planned start, the carbon intensity in gCO₂e/kWh with and without the wait, and the saving. On a grid that’s already clean and steady, most runs will simply start on time. That’s the rule working, and you can read it in the response.

Agents you keep

Transcript

A run is one task. An agent is a job you keep. Describe the work in the chat. GreenPT asks the few things it needs, then drafts the agent: its instructions, its schedule and a task to test it. Keep it, and it has its own page, with every run and every result. On a schedule, nobody is there to answer. So the run isn’t given a way to ask. By API, it’s one call to create, and one address to run. Work you describe once, done again and again.

A run is one task. An agent is a job you keep.

Describe the work in GreenPT’s chat, and it asks the few things it needs to know: when the work should run, how the result should reach you, and whether the job may wait for cleaner electricity. Then it drafts the agent, with its instructions, its schedule and a task to test it. Nothing is saved until you accept it. Keep it, and it has its own page, with every run and every result.

A scheduled run is different from one you’re watching, because nobody is there to answer. So a scheduled run isn’t given a way to ask. It works the brief with what it has, and it reports what it couldn’t do.

Developers get the same thing in two calls: one to create an agent, and one to run it at its own address.

POST /v1/agent-profiles
POST /v1/agent-profiles/weekly-report/runs

Every step on the record

Transcript

You shouldn’t have to take an agent’s word for it. Every run streams what it does: each step, each tool call and each result. It also records what it decided about itself: how the task was graded, which plan it took, and the budget it got. Fourteen rules hold for every trace, whatever the model chooses, and tests hold them to it. Its model calls report their energy and emissions, so a run adds up to a number, in watt hours. Every step, on the record.

You shouldn’t have to take an agent’s word for it.

Every run streams what it does: each step, each tool call and each result. It also records what it decided about itself, as decision events: how the task was graded and how sure the grade was, which plan it took, what budget it got, why it stopped. If a classifier timed out, the trace says so, because “never classified” and “classified as general” are different facts.

Fourteen rules hold for every trace, whatever the model chooses: a tool call is always answered, steps never overlap, a plan always comes before execution, a run never ends twice. Tests hold the runtime to them, so a regression shows up as a failed rule and can’t hide inside the normal variation of a model.

And a run adds up to a number. The model calls in a run report their energy and emissions through the same impact report as every GreenPT API response, and the run keeps the total. Our digest used 1.96 Wh and 0.14 g CO₂e. Across 21 finished runs in one benchmark on our test stack, the range was 0.49 Wh to 13.61 Wh, with a median of 4.7 Wh. These totals cover the model calls in the run’s own loop. The Metis grade and non-model tools such as search aren’t in them.

Why we think this is different

Most agent frameworks give you parts. Mangrove is a finished run, with opinions:

• It judges before it spends. A decision model sizes every task in milliseconds, without writing a word.
• It has a sense of enough. Budgets come from the task, and they’re enforced outside the model.
• It can’t quietly claim success. A run that failed says it failed, with a reason.
• It keeps what you paid for. Running out of budget ends in an answer that names its gaps.
• It knows what it used. Energy and emissions come with the run, in Wh and grams.
• It can wait. A run can hold for a cleaner hour, and tell you what that saved.

What Mangrove doesn’t do

A run is one exchange. It starts from a blank slate, it can’t be resumed, and a follow-up is a new run, so quote the part of the last answer you want built on.

A run’s cost isn’t known when it starts, because Mangrove decides how many steps a task needs. Two runs of the same question can cost different amounts.

A task that needs more than twenty rounds comes back thinner rather than failing. Splitting it into narrower questions helps.

Where it stands

Mangrove is in private beta, on the Pro, Pro Max, Teams and Enterprise plans, and runs are paid from your API credits. During the beta, not every capability in this article is switched on for every account. The digest run at the top of this article came from our test stack, with all of them on.

If you’d like to try it, the Mangrove documentation has a quickstart and worked examples, and you can ask for access on our Discord.

Tell us what you’d hand it first.