How Wandero Works
Inside the sandbox, filesystem, tools, skills, approval flow, and context architecture that turn a general AI model into Wandero’s travel operations platform.
The model is no longer the product.
That is not a contrarian take anymore. It is becoming the consensus among the people building the frontier. Greg Brockman said it plainly: "the model alone is no longer the product."
His fuller version is the one worth keeping. The model used to be the whole thing. Now it is one part of it. The software around it used to be a thin layer. Now it is a very fat one, and you have to build both together.
Garry Tan, the president of Y Combinator, put it on stage: "the 2x people and the 100x people are using the exact same Claude... the leverage is not in the weights, it's in how you wire the work." Aravind Srinivas built Perplexity on the same bet: models get commoditized, and the value moves to the experience and orchestration layer on top.
The tell is simple. When you can swap the model underneath without changing the workflow on top, the model is a commodity. The product is everything else.
We built Wandero on exactly that bet. It is one general agent that runs a travel agency's whole operation: triaging the inbox, pricing trips, generating itineraries, coordinating suppliers, running the long jobs that take hours. The model is interchangeable. The system around it is the product.
There is even a number for it. A widely cited community analysis of the Claude Code source, surfaced in the UCL "Dive into Claude Code" paper, estimates that about 1.6% of the codebase is AI decision logic. The other 98.4% is the operational infrastructure around the model. We found the same shape in our own work.
Primitives, not predictions. A small set of general tools, applied many ways, beats a catalog of special cases. That bet is what let five people rebuild the entire platform in three weeks.
So this post is that other 98.4%. The six pieces of infrastructure that make Wandero work: the sandbox, the filesystem, the tools, the skills, the interrupt flow, and the context management. Plus the patterns that fell out of building them.
The sandbox
The agent writes code and runs it. That is the whole shape of the work, whether the task is a pricing calculation, an itinerary draft, an email reply, or a supplier-coordination job that runs for an hour.
If that code runs in the same process as the rest of the platform, the model is one prompt injection away from the company's production data. So the agent does not get to live there.
Every conversation runs in its own isolated cloud sandbox. An ephemeral Linux box with its own filesystem, its own network scope, its own process tree. The first message in a session cold-starts a fresh box. The rest of the session reuses it warm. When the session goes idle, the box is destroyed. Nothing survives inside it unless it was written back to durable storage.
The sandbox is not bare. It boots from a prebuilt image with the tools the work needs already installed: an office suite, PDF and OCR tooling, document conversion, a Python data stack, a Node runtime. So when a skill has to read a contract PDF or write an Excel sheet, it just runs. No install step first. And when the agent needs something we did not ship, it can still pip install or npm install on the fly. Those runtime add-ons simply never get synced back.
The other half of the design is what the sandbox does not get: real credentials.
The agent's tools call out through a control plane that holds the actual API keys. The sandbox only ever sees short-lived, tightly scoped tokens. Every outbound request passes through a proxy that checks the token, confirms the action is allowed under the current scope, and only then makes the real call with the real key. The unsafe path is not blocked by policy. It does not exist.
This is the pattern Kyle Jeong described from inside Browserbase:
"Credential brokering means we don't have to just 'trust the model'; we can just remove its ability to do wrong."
Access is scoped before the agent ever sees it. The control plane decides which of the company's files each user's agent can touch: an admin's agent can read and edit them, a regular operator's can only read them. Only the permitted files load in. The agent acts freely, but only ever on the files that user is allowed to see.
Today the sandbox runs on Modal. Fast to start, cheap to run, genuinely good at this. It is also a dependency we are honest about. In the last month it went down two or three times, half an hour to an hour each. A managed provider buys us isolation and speed we would otherwise spend months building. The price is that their bad day is our bad day.
The layer underneath agent sandboxes is still settling. AWS just shipped a managed service aimed right at this, and we expect to try it. If you have run agents on it, or on something better, tell me what you found.
The cost is latency on the first turn. A cold start takes a few seconds while the box builds and the session's files load in; every turn after is basically instant.
The filesystem
The agent needs context. Company guidelines. The user's preferences. Past conversations. Domain capabilities. The current session's state.
The instinct is to stuff all of that into the system prompt and let the model carry it. That is what we did in the first version of Wandero. The prompt grew to 26,000 tokens. A wall of every variation we had ever seen and every behavior we had ever needed to spell out. Every new client made the wall taller.
The rebuild flips it. Everything the old version tried to cram into the prompt is now a file in the sandbox:
/home/
├── company/ # the agency's operating context
│ ├── overview.md # who they are, what they do
│ ├── guidelines.md # tone, brand, policies
│ ├── memory.md # things they've taught the system
│ ├── inventory/ # destinations, hotels, suppliers
│ ├── supplier/ # supplier-specific files
│ ├── policies/ # cancellation, pricing, refund rules
│ ├── resources/ # reference material
│ └── settings/ # currency, exchange rates, pricing config
├── me/ # the individual user's slice
│ ├── memory.md
│ ├── instructions.md
│ └── agent_config.json
├── sessions/current/ # this conversation's workspace
│ ├── workspace/ # working files
│ ├── itineraries/ # generated trip plans
│ └── attachments/ # uploaded files
└── skills/ # capabilities the agent can load
└── {slug}/SKILL.md
The agent does not memorize this tree. It navigates like a developer: ls, grep, read the file that matters. Most turns load a tiny fraction of what is there. A long session never pays to carry the whole company in every prompt.
And it is not just data that lives as files. The agent's own config does too. me/memory.md is what it has learned about a user. me/instructions.md is how that user wants it to behave. me/agent_config.json holds settings down to the interrupt policy, the rules for which actions need approval. Each one is a real file the agent can read, and where we allow it, rewrite. The change syncs back to the database underneath. The agent's setup and the agent's context are the same surface. It can change how it works, not just what it knows.
The filesystem is also where state survives across sessions. What the agent writes to me/memory.md shows up in the next conversation. Itineraries written into sessions/current/itineraries/ are kept as durable artifacts.
The mechanism behind that is the most intricate part of the whole system. There is no always-on disk. When a session wakes up, we spin up a sandbox and hydrate it: the files that session needs get streamed in from durable storage and unpacked into the local filesystem. While the agent works, every write and every shell command is followed by a sync. We diff what changed, what was created, what was deleted, and push exactly those files back.
We deliberately do not run a background file watcher. Watchers race with the agent and fire on half-written files. So the sync runs after each operation, when the change is actually done. Durable storage is the source of truth. If the sandbox dies mid-session, nothing important is lost, because everything that mattered was already written back.
This is why there is a cold start at all, and why the system is complex: hydrating a filesystem and syncing every change back out is a lot more machinery than keeping a server running. We pay it for clean, throwaway isolation, which is exactly what you want when the thing running code is a language model.
This is the principle Jerry Liu, founder of LlamaIndex, calls "files are all you need":
"Files are becoming the primary interface for AI agents to manage context, store conversations, and access skills."
We are not the only ones who landed here. Claude Code's MEMORY.md. Codex's AGENTS.md. OpenClaw's soul files. Hermes's USER.md. Every serious production harness today is some version of "the agent works against a filesystem." Each one keeps its own setup and its own conversations as files in a tree. Some use JSON, some TOML, some YAML. The format does not matter. The idea does: build a filesystem around the model, laid out the way a model reads best, so it can find, process, save, and update its own context without anyone spoon-feeding it.
The trade-off is access cost: reading a file is slower than reading a constant from the prompt. We pay it for legibility, and because the filesystem grows without bloating any single prompt.
The tools
The sandbox is where the agent acts. The tools are what it acts with. There are not many of them, and that is the point.
A small set is always loaded, every turn:
- read, write, and edit files
globandgrepto search them- a terminal for anything a shell can do
- a document parser for the PDFs and spreadsheets that fill a travel inbox
- web search and page fetch
- an email tool, a calendar tool, and a messaging tool
That last group is where the design shows. There is one email tool, not three. It works the same whether the account is Gmail, Outlook, or Zoho, with a provider layer underneath doing the translation. One calendar tool covers Google and Microsoft the same way. The agent learns one interface. We absorb the differences. Fewer tools, more reach.
Not everything is loaded up front, though. Carrying every possible tool in the prompt is the same mistake as carrying every possible instruction. It bloats the context and dulls the model's choices. So the tools the agent only needs sometimes stay out of the prompt until it asks for them.
The agent has a tool_search meta-tool. When a task needs a capability that is not loaded, it searches, and the matching tools get attached to its next turn. Capability shows up on demand instead of sitting in the prompt as dead weight.
This is the same "deferred loading" Anthropic's Claude Code team now describes: a large tool surface that costs zero context until the agent goes looking for it.
Here is the fun part of what that unlocks: the agent is not trapped in one conversation. Through these on-demand tools it can search and read its other sessions, their files and their transcripts. It can create, rename, organize, and even kick off work in them. All under the same permission checks a human hits in the UI. An operator can ask the agent, in one thread, to go check what was promised in another. And it can. There are guardrails: one run can only reach a bounded number of other sessions, and it cannot stop or delete the session it is running in.
The skills system
A vertical agent does a lot of different things. Travel alone means flight research, hotel comparisons, itinerary generation, pricing math, supplier coordination, booking, contract drafting, CRM updates, operational dashboards, public-link generation. Wire every one of those into the system prompt and it collapses under its own weight. That is what happened in the first version.
The current prompt is small. The capabilities live in a skills directory the agent reads at runtime.
Each skill is a folder with a SKILL.md at the top: a small block of frontmatter that names the skill and says when to load it, then the actual instructions, scripts, and where needed, secret bindings.
Skills resolve in three tiers:
- platform-global skills, available to everyone
- organization skills the agency has enabled
- user skills an individual operator has turned on
Enabling a skill copies it into that scope, so it can be tuned there without touching the layer underneath.
The agent finds its capabilities by reading the directory. Nothing about the itinerary skill is in the system prompt. The agent discovers it the moment a planning task shows up. Nothing about the supplier-booking skill is hard-coded. It lives in a folder the agent loads when a booking is in play. The prompt got dramatically smaller, and stayed small, because we stopped telling the agent what it can do and started letting it find out.
This is the pattern Anthropic's Claude Code team documented from the inside and the Perplexity skills team made canonical in their published manual. The Perplexity manual has one finding that should be load-bearing for anyone building this stuff:
"Self-generated Skills provide no benefit on average, showing that models cannot reliably author the procedural knowledge they benefit from consuming."
Curated by humans, skills work. Generated by models, they don't. The agent is great at running well-written instructions. It is not yet good at writing them. So we treat the skills directory that way. Every skill is reviewed, kept short, and updated when a production failure exposes a gap.
That is why our core skills, itinerary building and pricing, inventory, the supplier-booking integrations, are written and refined by hand, not generated. Each one went through several rounds in production until it was reliable, powerful, and easy for the model to pick up and use right.
This is the difference between an agent that can do something and one that does it reliably. In theory it could do most of this with the terminal alone: it has a shell, it can write code, it could reinvent a pricing calculation from scratch every single time. In practice that is slow, inconsistent, and every so often wrong in a way that costs a client money. A hand-built, tested skill encodes the right way to do a recurring task once, so the agent does it the same fast, correct way every time. This is where a general agent becomes a travel agent.
The trade-off is discovery cost. The agent has to find the right skill for the task, which is an extra file read or two at the start of a session, plus the occasional miss. We take that for the alternative: a small prompt that scales to dozens of capabilities without rewriting itself.
The interrupt flow
Long-running agents touch customers and real money. Most of what they do is safe: draft a reply, prepare a quote, generate a first-pass itinerary, update an internal record. One thing is not: sending a message out. The moment the agent is about to email or WhatsApp a client or a supplier, something leaves the building on the agency's behalf, and the system has to stop and check first.
So before an outbound message actually sends, the loop pauses, the state is checkpointed, and the proposed email or WhatsApp shows up in the agency's UI as an approval request. The user can approve it, reject it, or approve it with edits ("send it, but change the subject line"). When the answer comes back, the message, or the edited version, goes out, and the loop picks up where it left off.
What makes this work for long jobs is that the agent does not sit on compute while it waits. The session is genuinely paused, checkpointed to durable storage, and resumed only when the human responds. The wait is indefinite by design. A research job can pause for approval at 4pm Friday and continue cleanly when the operator is back Monday morning.
The same pause-and-resume machinery does one more thing: the agent can schedule its own future work. A price check tomorrow morning, a follow-up next week. When that time comes it wakes the session as if a new message had arrived, and anything high-stakes still stops for approval. Anthropic's Claude Code team is building toward the same shape with Claude Tag, which schedules its own follow-ups and, as Boris Cherny puts it, "will do the work, even if it takes days or weeks."
This is what João Moura, founder of CrewAI, calls the 90/10 rule:
"90% automated, 10% human-augmented. The exact ratio varies — some systems start at 30/70 and scale from that. The point isn't the number. It's having the architecture that supports both, so you can dial the ratio based on what the use case needs."
Approval is part of the product, not a weakness. As Harvey, building agents for legal work, puts it: "delegate the work, own the judgment."
Context management
Production agents run long, and eventually the context window fills up. Everyone handles this the same way: summarize the older turns into a recap and keep going. Two things about it are worth saying, because they are the ones that cost real money when you get them wrong.
The first is when you compact. We summarize well before the window is technically full. In production, quality degraded badly long before the hard limit, so we keep every session inside an effective context size that stays well under the model's maximum. Waiting for the wall is the worst option twice over, because the model is also at its least capable at summarizing exactly when its context is most polluted, as Thariq on the Claude Code team puts it.
The second, and the one that actually matters, is the prompt cache. Model APIs cache by prefix: everything from the start of a request up to the first thing that changes is reused cheaply, and the moment you touch something early, every token after it is recomputed at full price. Mismanage this and the bill balloons for no visible reason, so the cache is not a detail you tune at the end. It is the constraint the whole context strategy is built around. It is why the system prompt and the tool set stay fixed for the life of a session, why the agent never swaps models mid-conversation, and why we only rewrite history at compaction, the one moment the cache is already dead so the surgery is free. We learned it the expensive way: an earlier design trimmed old tool outputs mid-stream and quietly cost far more than summarizing, because every edit broke the cache. Cognition put the rule cleanly: routing is a caching problem. Do the disruptive work at the cache boundaries you were going to pay for anyway.
Summarization loses detail, so nothing important is left to depend on it. The agent has full run of the filesystem, so it writes what matters to persistent files, me/memory.md and session notes, and pulls it back on a later turn.
The patterns that fell out
This is the part that matters most, and it is barely about Wandero at all.
Step back from the six subsystems and the same shapes keep repeating. Not just in our system, but independently, in every other serious production harness. For each one below, the point is not that we do it. It is that everyone does.
- Brain and hands are separate. The model reasons, the sandbox executes, the credentials sit where neither can reach. Browserbase, Codex, Hermes, and Claude Code all landed here.
- The agent finds its own capability. Skills and tools live on disk and get loaded by reading, not baked into the prompt. Claude Code's skill loading, Anthropic's open
skills/registry, and Perplexity's manual are all versions of this. - Files are the durable surface. Context, state, history, artifacts, everything that has to survive a turn lives as a file. Claude Code, Codex, Hermes, OpenClaw, and Letta all converged on it.
- Approval is part of the product. High-stakes actions pause for a human, and the agent burns no compute while it waits. Harvey scaled it into legal, CrewAI into enterprise ops.
- Compact before you must. Summarize early, because the model is dumbest exactly when the context is most polluted. OpenClaw, Codex, and Claude Code all encode the same rule.
- Primitives, not predictions. A small set of general tools beats a catalog of special cases. Every feature built for one client is a hack you maintain forever, so we leave it out.
When independent teams land on the same architecture without coordinating, that is physics, not opinion. The patterns above are not ours.
The convergence even has a technical explanation. Aparna Dhinakaran's code-verified comparison of Pi, OpenClaw, Claude Code, and Letta found the same handful of design choices everywhere: ~2,000-line file read caps, offset/limit pagination, LLM-powered compaction, isolated sub-agent sessions. Her word for it: "emergent solutions to physical constraints." Ours is blunter. 50 years of OS memory management is repeating in agent context management.
The harness, in Harrison Chase's framing, is one of three pieces every modern coding agent is built from: model, runtime, harness. The shape is shared. What separates one production system from another is the harness, because the harness is the part you tune for the actual domain.
Primitives, not predictions. A small set of general tools, applied many ways, beats a catalog of special cases.
What this means
The model is becoming a commodity. The one you build on today is not the one you will ship six months from now, and the architecture has to assume that. What stays is everything around it.
OpenAI's Codex team named this discipline "harness engineering." Ryan Lopopolo, who led the work, put the rule simply: when the agent fails, do not prompt it better or tell it to try harder. Ask what capability, context, or structure is missing.
The bug is rarely in the model. It is almost always in the system around the model. Fix the environment, not the agent.
OpenAI put a number on it. Same model, same weights, and two harness settings took its ARC-AGI-3 score from 13.3% to 38.3%, with six times fewer output tokens. Their own conclusion: "evals rarely measure models in isolation—they also measure a bundle of less visible choices about API settings, harness design, and prompting."
For a vertical product like Wandero, the harness is also the moat. Travel has rules: supplier contracts, refund policies, currency conversions, seasonality, brand voice, agency-specific guidelines. None of that lives in any public model. It lives in the company's filesystem, its skills, its policies, its interrupt rules, its approval flows. The model executes. The harness is what makes it correct for the agency.
The interesting question is no longer whether agents can run production work. We know they can. It is which of these shapes become standard, and how fast the field converges on them. Our bet is that it keeps converging.
The model is interchangeable. The system around it is the work. Primitives, not predictions.
