{
  "segments": [
    {"speaker": "host", "text": "Welcome back to Learning Curves. I'm your host, and today we're tackling something I've been excited about — building AI agents you can actually ship to clients. Not just prototypes. Real, maintainable, modular things that businesses will pay for and keep paying for. And joining me is someone who's coming at this from a really practical angle — a web developer with years of client work under their belt, but new to the agent space."},
    {"speaker": "learner", "text": "That's me. I've built a lot of websites and SaaS tools for clients over the years — WordPress, SvelteKit, React — and I keep hearing about AI agents. But every time I look into it, I hit a wall of jargon. LangChain, function calling, tool-use loops, agent orchestrators. I can't tell what's hype and what I actually need to learn."},
    {"speaker": "host", "text": "And that is exactly the right question to ask, because the agent space is drowning in hype right now. So let's start with the most fundamental thing — what actually makes something an agent versus just a chatbot with a nice prompt?"},
    {"speaker": "learner", "text": "Yes please, because I feel like every company is slapping \"AI agent\" on their product and I don't know what it actually means anymore."},
    {"speaker": "host", "text": "[laughs] Fair call. Here's the simplest way to think about it. A chatbot makes one LLM call and gives you an answer. Done. Vending machine — insert query, get response. An agent wraps that LLM call in a while loop. It calls the model, the model might say \"I need more information\" or \"I need to take an action,\" so the agent does that, feeds the result back into the model, and keeps looping until the task is actually complete."},
    {"speaker": "learner", "text": "Wait — so the difference is literally a while loop?"},
    {"speaker": "host", "text": "Literally a while loop. That's it. The architecture across every major player — OpenAI, Anthropic, Google — is the same five stages. The agent perceives, reasons about what it needs, plans the next step, takes an action, observes the result, and loops back. If the task is done, it returns. If not, it keeps going."},
    {"speaker": "learner", "text": "Okay, that actually demystifies it a lot. So the agent is the loop, and everything else is just... what goes inside the loop?"},
    {"speaker": "host", "text": "Exactly right. And that mental model is your superpower, because it means you — as an experienced web developer — already know how to build modular systems. An agent is just the orchestrator that decides which module to call next. The modules themselves are tools."},
    {"speaker": "learner", "text": "Tools being... API calls? Functions?"},
    {"speaker": "host", "text": "Exactly. You define a function with a name, a description, and a JSON Schema for the parameters. The LLM decides when to call it and with what arguments. Your code executes it and feeds the result back. So you define tools like getCustomerOrders, checkInventory, bookAppointment, lookupKnowledgeBase. The agent brain just decides the order."},
    {"speaker": "learner", "text": "So the tools are the actual value to the client. Not the agent loop itself."},
    {"speaker": "host", "text": "[snaps fingers] You just nailed the most important insight of this whole conversation. Your client doesn't care about the agent loop. They care that it can check their Shopify inventory, look up a customer's order history, and answer support questions from their knowledge base. The value is in the integrations you build. The agent is just the brains that wires them together."},
    {"speaker": "learner", "text": "That changes how I think about packaging this. If the tools are the value, I should be building a toolkit, not a one-off agent per client."},
    {"speaker": "host", "text": "Yes! And this is where your experience building modular client systems pays off. The smartest pattern I've seen — and this comes straight from Anthropic's own architecture guide — is to separate everything into layers. Tool definitions live in one place, system prompts in another, model selection in config, knowledge sources are pluggable. Each layer can be swapped per client without rebuilding the whole thing."},
    {"speaker": "learner", "text": "So I build a core agent engine, and then per client I configure which tools they need, what knowledge base to connect to, and how the agent should behave?"},
    {"speaker": "host", "text": "Exactly. And there's an emerging standard making this even cleaner — it's called MCP, the Model Context Protocol. Think of it as USB-C for AI tools. Instead of writing custom integration code for every client's CRM or database, you point to an MCP server that exposes those tools in a standard format. Your agent just discovers what tools are available and uses them."},
    {"speaker": "learner", "text": "Okay that sounds huge for client work. But let me ask the question that's on my mind — what about frameworks? I keep hearing LangChain mentioned everywhere. Do I need it?"},
    {"speaker": "host", "text": "This is where I'm going to say something that might surprise you. The overwhelming consensus from people actually running agents in production — and I mean real, deployed, client-facing agents — is to start without a framework. Anthropic themselves say the most successful implementations use simple, composable patterns, not complex frameworks."},
    {"speaker": "learner", "text": "Wait, really? So LangChain is just hype?"},
    {"speaker": "host", "text": "Not hype, but it solves a problem you probably don't have yet. A basic agent loop is under a hundred lines of code with a raw provider SDK. LangChain and LangGraph add abstraction layers that make it harder to debug, harder to see what's happening with prompts and responses, and tempt you into over-engineering before you've proven the simple version won't work. There's a famous Hacker News comment where a team said they ripped LangChain and LangGraph out of their project because they were \"literally worthless, just adding complexity.\""},
    {"speaker": "learner", "text": "[whistles] That's strong. So what's the right starting point for someone like me? I'm a TypeScript dev, I build in SvelteKit and Next.js a lot."},
    {"speaker": "host", "text": "The Vercel AI SDK is your sweet spot. It's a thin wrapper over the provider APIs that handles streaming and tool calling cleanly, and it's built for the TypeScript ecosystem you're already in. The ToolLoopAgent they introduced in version six covers most embedded-agent use cases. You get the loop, tool execution, and streaming without LangGraph's complexity. And when you genuinely outgrow it — which you might not for a while — you can add orchestration on top."},
    {"speaker": "learner", "text": "Alright, so start simple, build a toolkit of reusable integrations, config per client. That's the architecture piece. But honestly, the thing that worries me more is the business side. I've had enough client projects where maintenance ate me alive. How do I not repeat that with agents?"},
    {"speaker": "host", "text": "[sighs] You've put your finger on the single biggest unpoken truth in the agent space. There's a Reddit thread that went viral from someone who built over thirty AI agents for real businesses. Their headline: building the agent is only 30% of the battle. Deployment, maintenance, and keeping up with API changes is the other 70%. And let me tell you the costs."},
    {"speaker": "learner", "text": "I'm ready. Hit me."},
    {"speaker": "host", "text": "A single agent loop uses about four times the tokens of a standard chat. Multi-agent systems? Up to fifteen times. Real production agents cost between five hundred and three thousand dollars a month in infrastructure, and the total cost — including your time maintaining it — is two to five times higher than the raw API cost you'd guess in planning. Plus you'll need about half a full-time equivalent of maintenance in the first year."},
    {"speaker": "learner", "text": "Half an FTE? So I can't just build and bill once. I need a retainer model."},
    {"speaker": "host", "text": "That is exactly the business model. The smartest play I've seen is tiered monthly subscriptions. Three hundred to five hundred for a starter agent with basic tools, up to fifteen hundred for something with deep integrations, human-in-the-loop review, and active monitoring. You're not selling a product. You're selling a service that happens to run on LLMs."},
    {"speaker": "learner", "text": "And what about when it breaks? Because LLMs are nondeterministic — I can't give a client a guarantee that it'll always give the right answer."},
    {"speaker": "host", "text": "This is where observability becomes non-negotiable. You need structured logging, token accounting, traceability on every decision the agent makes. Tools like Langfuse or Helix let you replay what happened — what prompt was sent, what tool was called, what data was retrieved. When a client says \"the agent gave a wrong answer,\" you need the receipts. And you need evaluation suites — a set of test scenarios you run before every deployment to catch regressions."},
    {"speaker": "learner", "text": "So observability baked in from day one. Tests like I'd write for any other client project, but for agent behaviour. And a retainer that covers ongoing maintenance."},
    {"speaker": "host", "text": "Now you're thinking like someone who'll actually succeed in this space. Let me give you one more piece that I think will land well. The research is very clear on what businesses actually care about versus what developers focus on. Developers obsess over which framework is coolest or whether they should use multi-agent orchestration. Clients care about reliability, cost predictability, integration with their existing systems, and support burden."},
    {"speaker": "learner", "text": "Classic. The stuff they can measure."},
    {"speaker": "host", "text": "Exactly. Can the agent book forty more appointments this month? Can it reduce support ticket resolution time? Does it work with their CRM? What happens on weekends when it breaks? Those are the questions. Nobody has ever lost a client deal because they didn't use LangGraph."},
    {"speaker": "learner", "text": "Okay, so if I'm going to start tomorrow, what would you have me do first?"},
    {"speaker": "host", "text": "Pick one client problem you already understand deeply. Could be appointment booking, support ticket triage, inventory lookups — something with a clear input and a clear output. Build a single-tool agent using the Vercel AI SDK or the raw OpenAI SDK. Wire it to that one API. Get it working end to end. Put logging on every step. Give it to one person to test. That's your minimum sellable unit. Don't think about multi-agent systems or complex RAG pipelines until you've shipped one thing and learned what breaks."},
    {"speaker": "learner", "text": "Start small, ship fast, charge monthly. I can do that."},
    {"speaker": "host", "text": "And when you do, you'll be ahead of ninety percent of people in this space. Because most people are still trying to build the perfect agent. You'll be the person who actually delivered something that works."},
    {"speaker": "learner", "text": "[short pause] That's honestly the best advice I've heard on this topic. Thanks."},
    {"speaker": "host", "text": "Thanks for the great questions. Here are the key takeaways: one — an agent is just a while loop around an LLM, not magic. Two — build modular tools, not monolithic agents; your client's value is in the integrations. Three — start without frameworks, add complexity only when you have data showing you need it. Four — price as a monthly service, not a one-time build, because maintenance is seventy percent of the work. And five — always, always build observability in from day one. That's it for this episode of Learning Curves. See you next time."}
  ]
}