AI Agents are not magic, but also are not as simple as "build an agent, automate everything, profit". Most people don’t understand what an agent is. Those that do (<5%) try to build one and it falls apart. The agent hallucinates, forgets what it was doing mid-task, or calls the wrong tool at the wrong time. It works perfectly in demos and breaks immediately in production. I've deployed agents for over a year now. I started my software career at Meta but left 6 months ago to build a company that does nothing but deploy production agents for enterprise. We're at $3M ARR and growing, not because we're smarter than anyone else, but because we've built and failed enough times to know what the formula is now. This is everything I've learned about building agents that work. It should apply at any level, whether you’re a beginner, an expert, or somewhere in between. My goal with this article is to share my biggest learnings from a few years of being in the AI space. My hope is that you walk away with useful information that you can use to build better agents. Let's begin. Lesson 1: Context Is Everything Yes this is super obvious and you’ve probably heard it before. But that's because it's true. Most people think building agents is about chaining tools together. You pick a model, give it access to your database, and let it figure out what to do while you grab a beer. This approach fails immediately for a few different reasons. The agent doesn't know what matters. It doesn't know what happened five steps ago. It only sees the current step in the process, guesses what to do (often poorly), and hopes for the best. That’s not the way that you want your agents to act, especially when you sell these agents to companies. Context is often the biggest difference between an agent worth $1M and an agent worth $0. Here's the concepts you need to focus on and optimize for: What the agent remembers. Meaning not just the current task, but the history of what led here. If an agent is handling an invoice exception, for example, it needs to know: what triggered this exception, who submitted the original invoice, what policy applies, and what happened last time this vendor had an issue. Without that history, the agent is just guessing, which is worse than if the agent didn’t even exist in the first place, because at that point a human would have figured it out. See: "AI sucks". How information flows. When you have multiple agents, or one agent handling multiple steps, information needs to move between stages without getting lost, corrupted, or misconstrued. The agent that triages incoming requests needs to pass clean, structured context to the agent that resolves them. If that handoff is sloppy, everything downstream breaks. That means structured input and structured output that is verifiable at each stage. An example of this step is /compact in Claude Code, handing off context between LLM sessions. What the agent knows about the domain. An agent handling legal contract review needs to understand what clauses matter, what risks look like, what the company's actual policies are. You can't just point it at documents and expect it to figure out what's important. That’s your job. But your job also includes being able to provide the resources in a structured format to your agent so that it has domain knowledge. Bad context management is an agent that calls the same tool repeatedly because it forgot it already got the answer, or calls the wrong tool because it was fed the wrong information. Another example is an agent that makes a decision contradictory to something it learned two steps earlier, or an agent that treats every task as brand new even when there's a clear pattern from previous similar tasks. Good context management means the agent operates like someone with domain knowledge. It connects dots across different pieces of information without explicit instructions on how they relate. This is why when I sell agents to enterprise, I say we truly can automate everything. This is because we build custom for businesses, and we span their entire existing knowledge base (whether that's documents or interviewing their employees) to make that happen. This is the concept that separates agents that just demo well from agents that run and deliver results when in production. Lesson 2: Agents Multiply Outcomes The wrong way to think about agents: "This will do the work so we don't have to hire someone." The right way is: "This will let three people do what used to require fifteen." Yes, agents are going to replace human labor, and if you say otherwise then you are respectfully delusional. The positive is that agents don't eliminate the need for human judgment. They eliminate the friction around human judgment. This can include things like research, data gathering, cross-referencing, formatting, routing, follow-up. You get the idea. A finance team still needs to make decisions about exceptions. But instead of spending 70% of close week hunting for missing documentation, they spend 70% of close week actually resolving issues. The agent did all of the work, but the human approves it. The reality of the situation, from what I’ve seen doing this for customers, is they never fire employees. There’s nearly infinite work for employees to do in place of their previous manual work, at least for now. I do anticipate this will change over time as AI replaces that too. The companies getting real value from agents aren't the ones trying to remove humans from the loop. Instead they are the ones who realized that most of what humans were doing wasn't actually the valuable part of their job, but rather the overhead required to get to the valuable part. Build agents this way and accuracy stops being a concern: the agent handles what it is good at, just like employees focus on what they’re good at. This also means you can deploy faster. You don't need the agent to handle every edge case. You need it to handle the common cases well and route the weird stuff to humans with enough context that the human can resolve it quickly. Again, at least for now… Lesson 3: Memory and State How an agent retains information across a task - and across multiple tasks - determines whether it works at scale. 3 patterns show up constantly: Solo agents that handle a complete workflow. One agent handling one job, start to finish. These are the easiest to build because all the context stays in one place. The challenge is managing state as the workflow gets longer. The agent needs to remember what it decided at step three when it gets to step ten. If your context window fills up or you're not structuring memory correctly, late-stage decisions get made without early-stage context, and stuff breaks. Parallel agents that work on different pieces of the same problem simultaneously. Faster, but now you have a coordination problem. How do the results merge? What happens when two agents reach contradictory conclusions? You need a clear protocol for how information comes back together and how conflicts resolve. Often time this means a judge (either a human or another LLM) that resolves conflicts or race conditions. Collaborative agents that hand off to each other in sequence. Agent A does triage, passes to Agent B for research, passes to Agent C for resolution. This works well when the workflow has natural stages, but the handoffs are where things break. Whatever Agent A learns needs to survive the transition to Agent B in a format that Agent B can actually use. Typically the agents that we deploy for enterprise are a mix of 2 and 3. The mistake most people make is treating these like implementation schematics, when in reality they're architectural decisions that determine what your agent can and can't do. If you're building an agent that handles sales deal approvals, you need to decide: Does one agent own the whole process? Or does a routing agent hand off to specialized agents for pricing review, legal review, and executive approval? Only you will know the actual process behind the decision making, which hopefully you can pass on to your fellow agent eventually. You can and should gather the information required to make a more informed decision by talking to the business or employees to figure out what their workflows actually look like, instead of just guessing. The answer depends on how complex each stage is, how much context needs to carry between stages, and how often the stages need to coordinate in real-time versus sequentially. If you get this wrong, you'll spend months debugging failures that aren't even bugs; they're architectural mismatches between your design, your problem, and your solution. Lesson 4: Catch Exceptions The default instinct when building AI systems is to create dashboards. Surface information. Show people what's happening. Please for the love of every single person on this planet do not create another dashboard. Dashboards are useless. Your finance team already knows there are missing receipts. Your sales team already knows deals are stuck in legal. Agents should catch problems when they happen and route them to whoever can fix them. With everything needed to actually fix them. Right then. When an invoice hits without proper documentation, don't add it to a report. Flag it immediately. Figure out who needs to provide what. Route it to them with the full context - the vendor, the amount, the policy that applies, the specific documentation that's missing. Block the transaction from posting until it's resolved. This last part is also crucial, because if you don’t do this, information starts leaking all over the org and you won’t have time to restore the problem. When a deal approval sits for more than 24 hours, don't surface it in a weekly review. Escalate automatically. Include the deal context so they can approve or reject without digging through systems. You have to move with urgency. When a supplier misses a milestone, don't wait for someone to notice. Trigger the contingency playbook. Start the response before anyone has to manually realize there's a problem. Your AI Agent’s job is to make problems impossible to ignore and incredibly easy to resolve. Surface the issue directly, rather than through a dashboard. This is the opposite of how most companies use AI. They use it to create visibility into problems. You should use it to force resolution of problems, and do so quickly. Only spend time making a dashboard once the problem is mitigated to near 100%. Lesson 5: Economics of AI Agents vs. Generic SaaS There's a reason companies keep buying SaaS tools that nobody uses (and it’s awfully painful to see). SaaS is easy to purchase: It has a demo, a price, and a checkbox next to the requirement you were trying to fill. Someone can approve it and feel like progress happened (even though this is rarely the case). The worst part purchasing AI SaaS is it just sits there. It doesn't integrate with how work actually happens, and becomes another system people have to log into. You're forced to migrate and after a month it's just another vendor to manage. Finally in 12 months it's abandoned and you're stuck with it because the switching cost is too high, resulting in what is called tech debt. Bespoke AI Agents built on your existing infrastructure don't have this problem. They operate inside the systems you already use. They don't create a new place to do work. In fact, they make existing work faster. The agent handles the task, while the human sees the result. The real cost comparison isn't license fees versus development cost, it's a lot simpler. SaaS accumulates “tech debt”. Every tool you buy is another integration to maintain, another system that will eventually go out of date, another vendor that might get acquired or pivot or shut down. Agents built in-house accumulate capability. Every improvement makes the system smarter, and every new workflow extends what's possible. The investment compounds instead of depreciating. This is why I have been preaching for the last year: AI SaaS is going nowhere. And the industry is confirming this stat: most companies purchasing AI SaaS churn within 6 months, and see absolutely no productivity gains from implementing AI. The only companies who see AI gains are those who have custom agents built specifically for them, either in house or by a 3rd party agency. This is why the companies that figure out agents early will have a structural advantage for years. They're building infrastructure that gets better over time. Everyone else is renting tools that will eventually need to be replaced. And when the space is changing every month, every week lost has serious implications for your roadmap and your business as a whole. Lesson 6: Deploy Time If your AI agent project has a year-long timeline before anything goes live, you've already lost. The plan won't survive contact with reality. The workflows you designed won't match how work actually happens, and the edge cases you didn't anticipate will be the ones that matter most. The entire AI space will look completely different in 12 months; you’re building a ghost. Get to production in 3 months max. In a world where information is abundant, your real skill is understanding how to utilize it effectively and working with it, not against it. Actually work: handling real tasks, making real decisions, with real audit trails. The biggest issue I’ve seen is that internal development teams will quote you 6-12 months for an AI project that should realistically take 3 months. Or worse, will tell you 3 months but after getting started keep pushing back the timeline for “unexpected reasons”. I can’t blame them - the AI world is hard. Which is why you need genuinely AI-trained engineers, who understand how AI works at scale, have witnessed and accounted for real-world AI scenarios, and know the capabilities and limitations of AI. There are too many phony developers who think AI can do absolutely everything - this couldn't be further from the truth. If you’re a regular software engineer looking to get into the field of applied AI at the enterprise level, you have to be well versed in AI’s real capabilities. TLDR: Building agents that work comes down to a few things: Context is the whole game. An agent without good context is just an expensive random number generator. Invest in how information flows, how memory persists, how domain knowledge gets embedded. Remember when you guys made fun of prompt engineers? Context engineers are just prompt engineers 2.0. Design for multiplication, not replacement. Let humans do what humans are good at. Let agents clear the path so humans can focus on that. Architecture matters more than model selection. Solo versus parallel versus collaborative agents is a bigger decision than which model you're using. Get the architecture right first. Catch and resolve, don't report and review. Dashboards are where problems go to die. Build systems that force resolution. Ship fast, improve constantly. The best agent is the one that's running in production and getting better, not the one that's still being designed (and watch your timeline) Everything else is details. If you're building agents - whether for yourself or for clients - these are the things that will determine whether you succeed or spend six months building something nobody uses. The technology is ready, you’re probably not. Figure that out and you 100x your business. If you’re a business owner thinking about implementing AI for your business, just book a free AI Audit with my company Varick Agents, and we’ll explore whether or not AI is a good fit for you + what a potential AI transformation would look like: book today at varickagents.com. And if you want more tips on how to get the most out of AI for yourself or your business, subscribe to our free weekly newsletter: varickagents.com/newsletter.