Meet Jordan Reyes: Your Guide to Building with AI Agents
Why This Site Exists, and What You Can Expect From It
Most resources about AI agents either stay at the level of marketing slides or dump you into raw API documentation with no bridge between the two. This site is the bridge.
My name is Jordan Reyes. I am a full-stack developer who spent the better part of a decade building conventional web applications before shifting, almost entirely, to building agentic systems. That shift started about three years ago when I kept running into the same frustrating wall: I could find plenty of content explaining what AI agents were, but almost nothing explaining how to actually build, debug, and ship them in a way that held up outside a demo environment.
So I built the resource I wish had existed. What follows is an honest account of my background, what I cover here, and how to get the most out of it depending on where you are in your own journey.
My Background and How I Got Here
I came up through full-stack development. That means I have a working relationship with databases, APIs, authentication systems, deployment pipelines, and the general messiness of keeping a production application alive. I am comfortable in Python and JavaScript, and I have spent time in the infrastructure layer — enough to understand what it costs when something fails at 2 a.m.
The turn toward agentic systems was gradual. It started with simple LLM-powered scripts: summarization tools, internal search over company documents, a few classification pipelines. Those were straightforward enough that existing tutorials could carry me through. Then the projects got more complex. I started building systems where a model needed to decide which tool to call, interpret the result, and plan its next step. I started working on multi-agent pipelines where one agent orchestrates several others across a workflow that might take minutes or hours to complete.
That is where most available guidance stopped being useful. The gap between a single-turn LLM call and a reliable, observable, multi-step agent system is enormous, and almost no one was writing clearly about how to close it.
I have made the mistakes you are likely about to make — or have already made. I have built retrieval systems where the retrieval was quietly wrong for weeks before I noticed. I have shipped agents with no fallback behavior that failed silently and expensively. I have over-engineered orchestration frameworks on projects that needed three functions and a loop. I have also, more recently, built systems that actually work well in production, and I have learned to tell the difference between the two before writing the first line of code.
What Agentic Systems Actually Are, and Why They Are Difficult
The term “AI agent” gets applied loosely, so it helps to be specific about what makes a system agentic and why that creates real engineering challenges.
A standard LLM interaction is stateless and single-turn: you send a prompt, you get a response, you are done. An agentic system introduces at least some of the following: memory that persists across steps, the ability to call external tools or APIs, the capacity to plan across multiple steps before acting, and sometimes the coordination of multiple models or subagents working in parallel or sequence.
Each of those additions creates new failure modes. Memory systems introduce retrieval errors and context window pressure. Tool use introduces latency, rate limits, and the possibility that a model will call a tool with malformed arguments or misinterpret its output. Multi-step planning means that an early mistake can compound through several downstream actions before anything surfaces. Multi-agent coordination adds scheduling complexity, communication overhead, and the genuinely hard problem of deciding which agent should own a given decision.
None of these problems are unsolvable. But they require a different mental model than conventional software development, and they require evaluation strategies that go well beyond “does it return something that looks right.”
What You Will Find on This Site
Everything here is implementation-focused. I try to write the tutorial I would have wanted before I built a given system myself. That means concrete architecture decisions, real code patterns, and honest discussion of tradeoffs rather than a celebration of whatever the newest framework happens to be.
The main areas I cover:
- RAG architectures. Retrieval-Augmented Generation is the foundation of most production knowledge systems, but the gap between a naive RAG implementation and one that reliably surfaces the right information is significant. I cover chunking strategies, embedding model selection, hybrid retrieval approaches, reranking, and the evaluation methods that tell you whether your retrieval is actually working or just appearing to.
- Agent orchestration frameworks. There are several mature frameworks for building agentic systems, each with real strengths and real constraints. I write about how to choose between them for a given use case, how to avoid being locked into abstractions that fight you when requirements change, and how to build orchestration logic that stays legible as a system grows.
- Tool use patterns. How a model calls tools, how you define tool schemas, how you handle errors returned from tools, and how you design tool sets that do not confuse the model — these are all non-obvious decisions with real consequences. I go into detail on each.
- Local model deployment. Not every workload belongs in a third-party API. I cover the practical side of running models locally or on your own infrastructure: hardware considerations, quantization tradeoffs, serving frameworks, and the cases where local deployment actually makes sense versus where it adds cost without proportionate benefit.
- Evaluation strategies. This is the area most tutorials skip entirely, and it is the area that separates systems that work from systems that seem to work. I cover both automated evaluation approaches and the human review workflows that catch what automated metrics miss.
Who This Site Is For
The primary audience is developers and technical professionals who are either actively building agentic systems or planning to start. You do not need to have worked with LLMs before, but you should be comfortable with programming fundamentals and have some exposure to APIs and web services. A lot of the content assumes Python familiarity because most of the agentic tooling ecosystem runs through Python.
I also write for small business owners and technical founders who are evaluating whether to build agentic tools internally or contract the work out. Understanding what these systems actually require — in terms of time, infrastructure, and ongoing maintenance — is genuinely useful even if you are not writing the code yourself. Several of the architecture and evaluation pieces are written with that reader in mind.
What this site is not: it is not an introductory guide to machine learning, and it is not a resource for AI researchers working on model training or novel architectures. There are excellent resources for both of those audiences. This site is specifically about the applied engineering work of building systems that use AI models as a component.
A Word on How I Approach Judgment Calls
Building with AI agents involves a lot of situations where there is no single correct answer. Which framework to use. Whether to build retrieval from scratch or use a managed service. How much autonomy to give an agent versus how many checkpoints to insert. When to use a powerful, expensive model versus a smaller, faster one.
I try to write about these decisions in a way that gives you the reasoning, not just the conclusion. My recommendation for a given choice depends on the specific constraints of your project, and a tutorial that just says “use this tool” without explaining when and why is not actually useful. I will tell you what I would do in a given situation and why, but I will also try to give you enough context to disagree with me intelligently when your situation differs from mine.
I am also willing to say when something is not yet good enough to rely on in production. There is a lot of enthusiasm in this space, and not all of it is matched by the maturity of the underlying tools. I would rather tell you that honestly than send you into a project underestimating what you are dealing with.
How to Get Started
If you are new to building agentic systems, the best place to start is with the foundational architecture guides. Understanding how memory, tools, and planning fit together conceptually will save you significant time when you move into implementation.
If you already have a system in progress and something is not working, the evaluation and debugging sections are probably where you want to go first. Most of the problems I see in agentic systems in the wild come down to retrieval quality issues, poorly defined tool schemas, or the absence of any systematic way to measure whether the system is behaving correctly.
If you have a specific use case in mind — automating a business workflow, building an internal knowledge assistant, creating a coding tool, orchestrating data pipelines — the applied tutorials walk through real implementations with the design decisions made explicit.
Browse the guides, work through the tutorials, and reach out if something is unclear or if there is a topic you need covered that I have not addressed yet. This site is built alongside the work I am doing, which means it improves when the people using it tell me where the gaps are. I am glad you are here, and I am looking forward to being useful to you.