Compiling the next screen…
Compiling the next screen…
A Next.js demo built to show genuine agentic reasoning: the model plans a weekend by calling real weather, search, and routing APIs, in an order it chooses itself, with every step visible in a live trace.
Most "AI agent" demos are a single model call wearing a trench coat: one prompt in, one generated response out, no real decision-making visible anywhere. That's easy to fake and easy to spot. It also doesn't show what applied AI engineering actually involves — tool design, failure handling, and an orchestration layer that survives contact with three real, independent APIs.
I wanted a demo that could not be faked: a model that genuinely chooses which tools to call, in what order, with what arguments, and shows its work on screen while it does it, using real weather data and real venues instead of invented ones.
I designed and built the whole system solo: the agent loop, the tool surface, the live trace UI, and the resilience layer underneath it.
Agent orchestration. The core is a streamText tool-calling loop from the Vercel AI SDK, capped at 6 steps as a safety ceiling. Claude Sonnet 4.6 decides which of the three tools to call, with what arguments, in what sequence, and when it has enough information to write the final plan — none of that sequencing is hard-coded. The system prompt explicitly tells the model to emit independent tool calls in the same turn so they run in parallel rather than serially; the trace shows two searchWeb calls firing back to back as a result.
Tool surface. Three custom tools wrap real third-party APIs: getForecast (OpenWeatherMap, up to 5 days of highs, lows, and precipitation), searchWeb (Tavily, real venue and restaurant search), and getDriveTime (OpenRouteService, driving minutes and miles between two named places, with geocoding handled internally). To be precise about what's AI and what isn't: the model chooses which tools to call and writes the final Markdown plan from their results — the tools themselves are plain, deterministic TypeScript wrappers around fetch calls. No AI runs inside them.
Live reasoning trace. Every tool call streams to the client as it happens and renders as a numbered row: the tool name, its arguments, and a short human-readable summary of the result, with a spinner while it's still running and a warning icon if it failed. The UI also supports showing any text the model emits between tool calls, so the trace can carry the model's own narration of what it's doing next, not just the calls themselves.
Resilience layer. Every tool returns a uniform envelope — { summary, data } on success or { summary, error } on failure — so the trace UI never has to guess the shape of a result. A shared fetch wrapper retries transient failures (timeouts, 5xx, rate limits) with exponential backoff and lets persistent failures (404s, missing API keys) through immediately, tagged with a code and an optional hint. Persistent errors go back to the model, not the browser console, so the agent can recover — for example, retrying a misspelled city with a corrected format instead of the whole run failing.
Final plan rendering. Once the model has enough tool results, it writes a structured Markdown plan — overview, Saturday, Sunday, what to pack — which streams into the page as it's generated, immediately below the live trace.
This was a self-directed project with no client and no other engineers involved. I owned the full stack: system prompt design, tool schemas, the retry and error-envelope pattern, the trace UI, and the deployment. I built it specifically to be inspectable — every architectural decision (step caps, parallelism, what the trace shows and hides) is documented inline in the code as a rationale, so it doubles as a reference for how I approach agent design, not just a working demo.
As a self-directed project, its value is demonstrative rather than commercial: a real, working proof that I build genuinely agentic systems — ones where the model makes real decisions and the app shows its work — rather than single-call demos dressed up as agents. It gives prospective clients and collaborators a concrete, runnable artifact to evaluate instead of a slide describing what an agent "would" do.
Three real APIs, one model-driven sequence, zero hard-coded tool order — the entire orchestration logic lives in a roughly 40-line system prompt and a 6-step loop, not a hand-written state machine.
Work directly with Cataluma’s principal consultant on the next useful technical step.