Scout: an agent that decides where to look

The last two residents of the Greenhouse were, underneath, a single call to a language model.

Sprout gets a persona plus a profile and replies. The Writing Bed fetches a few relevant paragraphs first, then replies.

In both, the flow is a straight line: text in, text out.

Scout 🔭 is different, and that difference is the whole point of this post.

You ask Scout a question and it decides what to do: search arXiv for papers, or check Wikipedia — sometimes both, sometimes twice.

Only then does it write an answer, with links to what it actually read.

That decision-making loop is what the word agent really means. Not a personality — a loop.

Pause & recall. What’s the difference between a program that calls a language model, and a program the language model drives? Sit with that for a second — it’s the hinge the whole post turns on.

The intuition: from a straight line to a loop

Here’s the shift, side by side. A plain LLM feature is a pipe:

An agent puts the model inside a loop and gives it a set of tools — things it can ask the program to do on its behalf.

The model no longer just produces an answer. At each step it produces a decision: “use this tool with these inputs,” or “I’m done, here’s the answer.”

Read that loop carefully, because it’s all an agent is: the model chooses an action, your code performs it, the result goes back to the model, and it repeats until the model decides it’s done.

People wrap this in frameworks and grand language. But if you can picture that diagram, you understand agents.

The rest is plumbing and taste.

From first principles: how does a model “use a tool”?

A language model only emits text. So how can it “search arXiv”?

The trick is a small, honest contract between you and the model:

1. You describe your tools in the request — each one a name, a sentence on when to use it, and the inputs it needs. Scout offers two:
   • arxiv(query) — “for research-level, technical or cutting-edge questions, or requests for papers.”
   • wikipedia(query) — “for general, encyclopedic knowledge: definitions, history, people, places.”
2. The model replies with a structured request, not prose — effectively “call arxiv with query: 'state-space models vs transformers'.” Models are trained to produce exactly this when tools are on offer.
3. Your code runs the real function — the actual HTTP call to arXiv — and hands the result back to the model as a new message.
4. The model reads the result and either asks for another tool or writes the final answer.

The model never touches the network. It only ever decides.

Your code holds every real capability. That’s the same safety principle as the Sprout post: the untrusted, clever part proposes; the code you control disposes.

Pause & recall. If the model only outputs text, and your code runs every real action, where would you put a limit like “never do more than three searches” — in the model’s instructions, in your loop, or both?

Scout’s loop, for real

Here’s an actual trace. You watch it scroll past as Scout works, because it streams each step back to you live:

Ask Scout a research question instead — “how do state-space models compare to transformers?” — and the first decision flips to arxiv. It pulls real paper abstracts and grounds the answer in them.

Same loop, different route. I never hard-coded the routing; the model reads the tool descriptions and picks.

That’s the small thrill of agents: you describe capabilities, and the model composes behaviour.

Two build choices worth defending

You can get an “agent” out of a framework in a few lines. I wrote the loop by hand, and I’d defend that for a project like this.

The loop is the risky part — the step ceiling, the spend cap, what happens when the model won’t stop. A framework tucks all of that behind abstractions; for something spending real money in public, I’d rather own every line and carry fewer dependencies.

To be precise about what “by hand” means: the model and the tool-calling primitives still come from LangChain — the same bind_tools the other residents use. What I kept in my own code is the loop around them — the brakes, the bounds, the decision to force a final answer. That’s the part I never want a library quietly deciding for me.

That calculus flips as orchestration gets hairy: many tools, branching plans, retries, a human in the loop. There, a framework starts paying for itself. Two tools and a strict allowance don’t clear that bar.

The second choice is the tools themselves — arXiv and Wikipedia. Both are free, need no API key, and hand back structured data I can parse.

More importantly, they pull in different directions: one for research, one for encyclopedic fact. That gap is what gives the model a real decision to make — and a single source would need no agent at all.

Knowing when to stop is a feature, not an afterthought

The scariest word in that loop is “repeat.” A loop that can call tools can also loop forever — or fire off twenty expensive searches for a one-line question.

So a huge part of building a good agent is building a bounded one. Scout has three brakes, each closing a real failure:

• A step ceiling. The loop runs at most a few times. If the model still wants to search after that, I stop asking and make it answer with what it has — which bounds both cost and latency.
• A hard daily cap. Scout is the most expensive resident by far: it fans out to external APIs and calls the model several times per question. So it’s capped at two questions per visitor per day, with a global ceiling on top. It’s a showcase, not a workhorse.
• Grounding, again. Same rule as the Writing Bed: answer from what the searches returned, and if they don’t cover it, say so. An agent that invents papers is worse than no agent — it launders a guess through the appearance of research.

The stop-limit answer, from earlier: put it in both. Tell the model “two or three searches at most” so it plans frugally. Then enforce a hard ceiling in your loop so a misbehaving model can’t overspend. The instruction shapes intent; the code guarantees the bound. Never let a limit that costs real money live only in a suggestion.

Why this is the interesting frontier

Notice what agents buy you, and what they cost.

They buy generality. I never wrote “if the question mentions papers, use arXiv” — I described two tools, and the model worked out the routing, the phrasing, and when one search wasn’t enough.

Adding a third capability tomorrow is a paragraph of description, not a rewrite.

What they cost is predictability. A pipe does the same thing every time; a loop driven by a model does plausible things that vary.

That trade — flexibility for determinism — is the real decision behind “should this be an agent?” For many problems the boring pipe is the right answer, and reaching for an agent is over-engineering.

Scout is an agent because the task genuinely benefits from choosing where to look. If there were only one source, there’d be no decision — and no reason for a loop.

Rebuild it in your head

Give a model a list of tools, each described by name, purpose, and inputs. Put the model in a loop: it either asks to call a tool — which your code runs, feeding the result back — or it declares itself done and writes the answer. Bound the loop with a step limit and a spend cap, and ground the answer in what the tools returned.

That is an agent. Scout is that, with two tools and a strict allowance.

Check yourself.

1. In one sentence: what makes something an “agent” rather than a plain model call?
2. The model can’t reach the network — so how does it “search arXiv”?
3. Name the three brakes on Scout’s loop and the failure each one prevents.
4. When would an agent be the wrong choice, and a simple pipe better?

The ones you can rebuild without peeking are yours for good. The ones you can’t just told you where to look again.

Make it yours

Across all three posts the throughline is the same, and it’s how I teach.

The techniques — grounding, retrieval, tool-loops — are the easy, portable part. The judgement is the valuable part.

Which problem in your own work deserves a straight pipe? Which deserves retrieval? Which genuinely needs an agent to go and decide — and where, honestly, does none of them belong?

Pick the smallest tool that solves a real problem for real people. That creates more impact than any amount of cleverness for its own sake.

Three residents, three shapes of one core idea: Sprout the grounded digital twin, the Writing Bed the open-book reader, and Scout the deciding forager.

Go try all three — Scout gets two errands a day, so make them good ones. 🔭