Emily: Hey everyone and welcome to Founder Stack, the podcast where founders and product leaders meet modern tech strategy. I'm Emily, your host from Responsive.

Rob: And I'm Rob, engineering lead here at Responsive. The rise of truly autonomous, agentic AI. We're really moving far beyond just, you know, a helpful co-pilot or some smart feature. We're talking about these highly sophisticated systems that are fundamentally changing how tech companies build workflows, run operations, and yeah, even design their product. And this isn't some far off future thing. It's happening right now. That's why it's such a critical strategic focus. Agentic AI is featured prominently on Gartner's list of top strategic technology trends for 2025, and their prediction for adoption speed is frankly staggering. By 2028, they think 33 % of all enterprise software apps will include some form of agentic AI. Wow, 33%. Just to put that in perspective, that's not some niche tool, right? That means one in three mission-critical applications is going to be driven by an autonomous system pretty soon. How fundamentally does that change things for, say, a CTO today? If you're building something new or even optimizing your internal systems, you almost have to adopt an agent-first mindset now.

Emily: You really do. So for you, listening right now, our mission is clear. We need to get past that copilot idea. We need to really understand what these autonomous AI systems are, how their architecture is so different from, you know, simple large language models, and crucially, how they achieve independent business outcomes without needing constant human babysitting.

Rob: Okay, let's start right there. Those terms, copilot and agent... They get thrown around a lot, sometimes interchangeably. They really shouldn't be.

Emily: No, they're drastically different. A copilot is, well, it's what we've mostly been using for the last couple of years.

It's an augmentation tool. Think Microsoft Copilot in Office or Jasper for Content, maybe the original GitHub Copilot for Code. Its job is basically assistance.

It boosts productivity, sure, by offering suggestions, generating drafts, automating maybe a single routine step. But the key thing is it always operates under direct human guidance. It doesn't take independent action. These are great tools, don't get me wrong. They typically give you a solid, say, 5 to 10 % productivity bump.

Rob: Right. So the copilot's like a really smart feature inside your existing software. What's the big leap with agentic AI? What defines it?

Emily: Agentic AI is fundamentally about being an autonomous system. It's capable of tackling complex, multi-step goals without constant human check-ins. They don't just wait for your prompt, they observe, they plan, they act, and they can even self-correct. It's kind of like mimicking human reasoning and problem solving, but over time, autonomously. Think of Waymo self-driving cars. That's a physical example. Or in the enterprise space, you have systems like Salesforce Agent Force for proactive customer work, or Resolve.ai for fully automated IT and HR support.

Rob: That distinction, autonomy versus just assistance, that must be what drives that huge jump in ROI you mentioned. We're talking potentially 20 to 50 % efficiency gains with an agent compared to maybe 10 % with a co-pilot. That kind of leap tells me this isn't just a slightly smarter LLM. There's got to be a completely different architecture under the hood. What is that? actually involved.

Emily: You're absolutely right. A simple LLM just can't do this alone. For agents to act independently, especially in a complex business environment, they need a pretty sophisticated operational stack.

Rob: Like what kind of components?

Emily: Well, OK, beyond the core reasoning model. Let's say that's a fine-tuned GPT class or maybe a Claude class model. You need systems for memory, for context, and for taking action. For context, you need something called the RAG architecture. It stands for Retrieval Augmented Generation. And it's crucial because it connects the agent to the company's internal structured knowledge. Think databases, manuals, passport tickets, internal docs. So the agent reasons based on your specific high-quality current data, not just general stuff from the internet.

Rob: OK, so RAG gives it the bright knowledge base. But autonomy means it needs to act and learn independently, doesn't it?

Emily: Yes. Exactly. And that requires things like vector search capabilities for memory and API integrations so it can actually use tools. The agent has to be able to recall past actions and outcomes, essentially forming short-term and long-term memory to stay consistent. Then, and this is really critical, you need orchestration frameworks, things like Lang chain or Crew AI.

Rob: What exactly do those orchestration frameworks do?

Emily: Think of them as the AI's project manager. They take a high level goal like fixing the notification issue and break it down into dozens of smaller actionable steps. They figure out the right sequence, decide which API tool is needed for each step, monitor the result, and then decide if a step needs repeating or correcting. Tom Kuscho from Gartner put it perfectly. He said, agents are systems that can plan autonomously and take actions to meet goals. That planning an action piece, that's what those orchestration frameworks enable.

Rob: That makes sense. And it leads us right to the founder perspective, doesn't it? When you look at an agentic system built on that kind of complex stack, it stops feeling like just another tool you subscribe to. It starts becoming like part of your company's operational structure, an autonomous, maybe even permanent teammate.

Emily: That's the mental shift exactly. Agent first. Instead of juggling a whole chain of fragmented tools, you deploy an agent to actually own the end-to-end outcome. We see the impact of this in real-world cases. Take the Black Angus case study. They deployed an agentic AI chatbot using endpoint automation. The result, it cut their after-hours support calls from 90 % of the total volume down to just 10%. That's a massive reduction in chaos handled autonomously.

Rob: And we've definitely had to embrace this internally ourselves. Not just for clients, but for our own operational reliability, we built an internal engineering agent. It's not just an alert system. It functions effectively like a full stack engineer who's permanently embedded, always awake, just monitoring the composable infrastructure for our client services.

Emily: And its real value isn't writing new features, but constantly watching that complex interplay between all those different tools, maybe 12, 15 different SaaS products that make up a modern stack.

Rob: Exactly. And building it requires that orchestration, using frameworks like Langchain and Crew AI. It needs vector search and memory. We use Pine Cone for that, so it maintained context over days or weeks. And really importantly, secure access control. using something like Clark to make absolutely sure it only touches what it's authorized to. The reasoning part comes from the fine-tuned models, yes, but the action comes from those integrations.

Emily: And the sheer scope of what it's monitoring is what makes the autonomy so powerful.

Rob: Yeah, I want to really emphasize that scope because this is where all the complexity lives today. This agent is actively correlating events across Vercel, SuperBase, Prisma, Hasura, PlanetScale, MongoDB, UpStash, CloudFlare, OneSignal, Mailgun, RedderStack, and RevenueCat. When you just list those out, you realize the agent is basically taking over the most chaotic context-switching grunt work an engineer usually gets stuck doing.

Emily: It's replacing hours and hours of manual log digging, for sure. Let's run through a quick scenario just to show that correlation power. Say a founder slacks the team late on a Friday night. Push notifications aren't reaching new users. Our churn analytics are spiking.

Rob: Right in the old world, that's immediate panic stations. An hour just logging into three different dashboards trying to figure out where to even start looking.

Emily: But the agent sees that message. It correlates it with the observability metrics it's already tracking. Instantly, it checks, say, the one signal logs for delivery failures. It verifies the rudder stack event pipeline is firing OK. It cross references super base triggers to see if new user signups are hitting the right database table. It connect those dots across the different tools and diagnoses the root cause. Maybe it's something like API key expired for one signal and the rudder stack event for user creation is being dropped. And it doesn't just diagnose. It instantly responds with that diagnosis and a proposed fix, maybe even drafting a safe patch or config change ready for review.

Rob: That right there is the definition of speed with context. It's not just alerting you to a fire. It's telling you what caused it and handing you the right extinguisher.

Emily: Exactly. It's the ultimate friction reducer for just day-to-day operations. It shifts engineering from being reactive to being proactively automated.

Rob: And speaking of shifts... We're seeing all the big players moving this way, from copilot towards agentic models. GitHub copilot is a prime example. It started as the classic pair programmer, but their new enterprise vision. That's all about turning it into a peer programmer with an agentic architecture built for independent problem solving and testing.

Emily: They actually talk about the agentic loop. That's where the agent plans, applies changes, tests those changes itself, and iterates on its own work before showing the final result to a human. And this shift is happening across the enterprise landscape. Salesforce has agent force. ServiceNow is going deep with now assist integrations for automating ITSM, which is where platforms like resolve.ai also play. Even Google's getting into the mix for developers with their open source agent Gemini CLI bring an agent power right to the terminal.

Rob: Okay, this raises a massive strategic question for founders then. Build versus buy.

Emily: Yeah.

Rob: You mentioned these complex orchestration frameworks like Langchain. Given how complex and critical reliability is, isn't there a huge risk, either vendor lock-in or maybe just automating your existing bad processes if you try to build your own agent from scratch?

Emily: That's a really essential question to ask. Building robust, reliable agents from the ground up using those frameworks can be very complex and frankly expensive. especially ensuring safety and reliability across a diverse tech stack. Now, if your problem is fairly standard, maybe IT ticket triage or common HR requests, then leveraging a purpose-built platform is probably the faster, safer path. But if you have highly unique proprietary operations, like monitoring that specific list of toll services you mentioned earlier, then building a specialized internal agent might be necessary to get the job done right.

Rob: Right. But regardless of build or buy, governance seems like it has to be absolutely non-negotiable. Especially when you've got autonomous systems potentially making changes in your production environment. How do we ensure trust?

Emily: Trust really boils down to auditability and control. The consensus emerging is that agents need to operate read-mostly by default. Any critical action, deploying code, changing a configuration, fixing a database schema that has to be staged, usually as a draft pull request or a proposed fix that requires human review. And crucially, you need a full audit trail recording every single step the agent takes, detailing its reasoning and the tools it used along the way.

Rob: So the human in the loop, or HITL, is still vital, not just for ticking compliance boxes, but actually for quality and judgment.

Emily: Exactly right. The baseline is the AI's error rate needs to be at least as good as, ideally better than, the human rate for that task. But even when the AI is super reliable, just removing the human entirely can sometimes destroy value. Look at that rock sales agent example. When they let the AI automatically send personalized outreach emails without any human review, the performance was way, way lower than when they kept the human salesperson in the loop to give it a final check.

Rob: And that difference was huge, wasn't it? Something like 333 times higher performance when the human was involved. What was the human adding in that case, that high level judgment?

Emily: Pretty much. The human provided that necessary strategic refinement, maybe some extra personalization. They could catch subtle context clues the AI missed. They might rephrase a nuanced offer slightly or just adjust the timing based on other conversations they were having. The agent provided the efficiency drafting the perfect message based on all the data. But the human applied the finesse, the ethical check, the relationship context that actually closes the deal.

Rob: OK, that brings us perfectly back to run books as this accountability layer. If the human is ultimately responsible for the final judgment and the agent is responsible for drafting the fix or the action, how do runbooks bridge that gap?

Emily: Runbooks essentially become the shared instruction manual. They're written by the engineering team and they guide the agent's autonomous actions. Often they're just structured documents, maybe simple markdown files like, you know, runbooks.gashit and validation.md. And these are linked directly to every fixed suggestion the agent proposes.

Rob: So these documents basically lay down the rules of the road for the autonomous system.

Emily: Precisely. They define the why behind a specific fix pattern. They detail exactly how to verify the issue is real, who needs to approve this type of fix, and critically, the safe steps to roll back if something goes wrong. The agent learns the fix itself, but the run book teaches it the team's culture of quality. It ensures every automated action adheres to best practices and safety standards.

Rob: That system really ensures that speed with context we talked about. The run book provides the essential context for the agent's incredible speed.

Emily: Absolutely. So let's try and summarize this agent-first mental model for you, the founder listening. The key idea is shifting away from managing lots of fragmented single-purpose tools. Instead, you replace them with autonomous specialized systems agents that own an entire quantifiable outcome.

Rob: Right. So your starting point shouldn't be, hey, where can I sprinkle some AI? Instead, start by identifying a really specific customer pain point, or maybe an internal point of chaos, or expensive, repetitive work. Define the target benefits you want, like Black Angus cutting after hours calls from 90 % to 10%. Then look for the agentic solution that can deliver that outcome.

Emily: And remember that efficiency point we covered. The AI doesn't actually need to be perfect, not out of the gate anyway. It just needs to be about as effective as a human doing that task currently, while also working cheaper, faster, and crucially, 24-7. That's how you unlock that transformational ROI and get real operational reliability.

Rob: OK, here's maybe a final provocative thought to leave you with. This big shift to agentic AI. It won't just drive efficiency by eliminating the tedious jobs nobody likes. It's going to fundamentally change the developer's role itself. By offloading all those repetitive context-switching tasks, like digging through logs from 12 different services, applying simple fixes, monitoring endpoints engineers get freed up, they can shift their focus to higher-level decision-making, to solutions design, to collaboration, tasks that are, frankly, usually the most fulfilling parts of the job.

Emily: Yeah, automation isn't really about replacement here. It's much more about elevation. Elevating the human work, focusing our energy where complex judgment and creativity matter most.

Rob: So if you're ready to explore how an embedded agent could seriously scale the reliability and response time of your specific tech stack, and if you want to start teaching an autonomous system, your team's culture of quality through Runbooks, then reach out. We'd love to connect and help you figure out how to design the agent that can start taming the chaos between your systems.