Why I Started BuildWithAgents: A Developer's Perspective
The Problem That Started Everything
Most side projects begin with frustration. This one did too, but the frustration turned out to be structural — not a quirk of one client engagement, but a gap that kept showing up everywhere I looked.
Three years ago I was building a document processing pipeline for a mid-sized professional services firm. The requirements sounded straightforward: ingest contracts, extract key clauses, flag anomalies, and route outputs to three different downstream systems depending on document type. Standard automation territory, or so I thought.
Rule-based systems fell apart almost immediately. Real contracts are messy. Language varies by jurisdiction, by author, by decade. A clause that means one thing in a vendor agreement means something different in an employment contract. The edge cases were not edge cases — they were most of the data. I needed something that could read context, hold state across multiple documents, and make routing decisions that a human reviewer would recognize as reasonable.
That project pushed me into language models, vector search, and eventually agent frameworks. What I found was genuinely powerful. It was also genuinely scattered. Excellent research, promising open-source tools, vendor documentation that assumed you already knew what you were doing, and almost no honest writing about how to put it all together in a system that would survive contact with production.
BuildWithAgents exists to be the resource I could not find then.
What “Agent” Actually Means in Practice
The word gets overloaded fast. Marketing uses it to mean anything with a language model attached. Researchers use it to mean autonomous systems with long-horizon planning. Neither definition is wrong, but neither is particularly useful when you are trying to build something that ships.
For the purposes of this site, an agent is a system that can observe inputs, reason about them, decide what action to take next, execute that action, and incorporate the result into its next decision. The key word is loop. A single call to a language model that returns a structured response is not an agent. An agent runs until it determines it is done, or until a constraint stops it.
That loop is where almost all the interesting problems live:
- How do you keep state across steps without the context window becoming a bottleneck?
- How do you handle tool calls that fail, return unexpected formats, or take too long?
- How do you know when the agent has reached a good stopping point versus when it is stuck in a low-quality loop?
- How do you give a human a meaningful way to inspect or intervene without breaking the workflow?
These are not theoretical questions. They are the questions that determine whether a system is usable in production or whether it gets quietly shelved after the demo.
Why Reliability Is the Only Metric That Matters
Early in my work with agents I made a mistake that I see constantly in teams building these systems for the first time. I optimized for capability. I wanted the agent to handle as many cases as possible, so I kept adding tools, broadening prompts, and relaxing constraints. The benchmark numbers went up. Real-world performance did not.
The problem is that agents operate in a compounding environment. Each step in the chain depends on the step before it. If step one has a ninety percent success rate and step two has a ninety percent success rate and step three has a ninety percent success rate, your end-to-end reliability is around seventy-three percent. Add two more steps at the same individual reliability and you are below sixty percent. A system that mostly works is often worse than no system at all, because it creates unpredictable failures that are harder to catch and correct than consistent failures.
This is why I spend more time writing about failure modes, fallback strategies, and observability than I spend writing about which model scored best on a benchmark. Benchmarks measure ceiling. Production requires floor.
Reliability in agent systems generally comes down to a few specific practices:
- Tight tool interfaces. Every tool the agent can call should have explicit input validation and explicit output schemas. Ambiguous interfaces produce ambiguous behavior.
- Step-level logging. You cannot debug a multi-step agent by looking at the final output. You need a trace of every reasoning step, every tool call, and every result.
- Graceful degradation. When a step fails, the system should have a defined behavior — retry, escalate to a human, return a partial result — rather than propagating garbage forward.
- Scope discipline. The hardest part of building a reliable agent is resisting the temptation to make it do more. Every capability added is a new failure mode introduced.
The Stack Questions I Get Asked Most Often
I am not going to tell you which framework to use. That answer changes as the ecosystem evolves and depends heavily on your specific constraints — language, team, latency requirements, vendor relationships. What I can share is how I think about the decisions that cut across frameworks.
Memory architecture matters more than model choice. Most agent failures I have diagnosed in real systems are not model failures. They are memory failures. The agent lost track of something it knew earlier, repeated a step it already completed, or acted on stale context. Before you spend time evaluating frontier models, make sure you have a coherent strategy for what the agent stores, where it stores it, and how it retrieves it. Short-term context management, external retrieval via vector search, and structured persistent storage each serve different purposes and should not be collapsed into one.
Chunking strategy is not a detail. If your agent is working with retrieved documents, the quality of your chunking directly caps the quality of retrieval. Splitting on arbitrary token counts destroys semantic coherence. Splitting on document structure — sections, paragraphs, semantic boundaries — preserves it. This is one of those areas where implementation choices made early are painful to unwind later.
Orchestration and execution should be decoupled. The component that decides what to do next should be separate from the component that does it. This makes the system easier to test, easier to observe, and easier to modify without breaking unrelated behavior.
Human-in-the-loop is a feature, not a fallback. The best production agent systems I have seen do not try to automate everything. They identify the decisions where automation adds clear value and the decisions where a human check is worth the latency cost. Designing those handoff points explicitly, rather than hoping the agent will figure out when to ask for help, is one of the clearest separators between systems that work and systems that cause incidents.
Who This Site Is For
BuildWithAgents is written for developers and technically literate professionals who are building real things and want honest, implementation-grounded guidance. That means:
- Developers integrating agent capabilities into existing products or internal tools
- Solo engineers and small teams at startups where there is no dedicated AI research function
- Technical founders who need to evaluate architectural tradeoffs without a team of specialists
- Professionals in adjacent fields — law, finance, operations — who have enough technical background to build but lack the AI-specific experience to know what they do not know
The tone here is practitioner to practitioner. I will tell you what I have found to work, what I have watched fail, and where I am genuinely uncertain. I will not tell you that any particular tool or pattern is the definitive answer, because this ecosystem moves fast and humility about that is more useful than false confidence.
What You Will Find Here
The content on this site is organized around the problems you actually encounter when building, not around the taxonomy of the technology. That means guides on retrieval and chunking live next to guides on prompt architecture, agent memory patterns, tool design, evaluation strategy, and production monitoring. The through-line is always practical implementation.
When I write about a technique, I write about it because I have built with it, broken it, and rebuilt it. I include the failure modes alongside the happy path because the failure modes are where the real decisions get made. I update content as the ecosystem evolves, because a guide written against a framework that no longer works the same way is worse than no guide at all.
The newsletter is where I surface the things worth paying attention to across the week — new tools that merit a real look, patterns I have been working through, and honest assessments of developments that are getting more hype than they deserve.
A Note on Where This Goes
The agent ecosystem is still early. The tooling is maturing faster than the best practices. That gap — between what is technically possible and what is practically reliable — is exactly where this site focuses its energy.
If you are building something with agents and running into the problems described here, you are not doing it wrong. These are hard problems. The goal of BuildWithAgents is to make them incrementally less hard by putting honest, specific, experience-grounded writing in one place.
Start with the guides most relevant to where you are stuck. If you are early in your architecture decisions, the memory and retrieval guides are the highest-leverage starting point. If you are already in production and dealing with reliability issues, the observability and failure-handling content will be more immediately useful. Either way, the newsletter will keep you updated as new material is added.
Build carefully. Ship things that work.