Art Vandelay, (Agent) Architect
Growing up, my dad worked at the paper mill. He'd get off, pick me and my sister up from school, and we'd head home, where he'd turn on Seinfeld while he "rested his eyes for fifteen minutes." I've been a fan ever since. The characters are the whole thing, and half of them had an alter ego: Bob Sacamano, H.E. Pennypacker, the Assman. My favorite was and always will be Art Vandelay, architect.
When I got into tech, everyone loved to talk about architecture, and it didn't take long to see why it mattered so much. Then AI and agents showed up, and it felt like we started trending toward just prompting a tool to do something and watching it do it. Now, as AI moves (fast) into the enterprise, I'm seeing teams get serious about architecture again, and about what it means for agents. For a PM, here's how I think about it.
Start with the customer, not the agent. Before any of the fun architecture work, do the unglamorous part: define the customer and work backwards from their problem. Who is this for, what job are they trying to get done, and where does the current process actually hurt? Write it down as a BRD or PRD. The business need, the specific problem, what "solved" looks like, and the success criteria you'll measure against. "Agentic" is an implementation detail, never the requirement. If you can't state the customer's problem in a sentence without using the word "AI," you aren't ready to build yet. This is what keeps you from shipping a clever agent nobody asked for.
Map the terrain, then draw the architecture. Now the how. Start by taking inventory of what already exists: which APIs and MCP servers can give you the data and actions you'll need. (MCP, the Model Context Protocol, is just a standard way to expose tools and data to a model. I wrote about it here.) That inventory does double duty: it also surfaces your dependencies, the things you have to solve before anything else works. Say a step needs finance data that lives in a system like TM1 with no MCP and no clean API. That isn't a detail, it's a prerequisite. You either build that connection first or, for the big critical systems where you often can't, design a workaround and accept its limits. The inventory is how you find those blockers before they find you.
From there, decompose the workflow into steps, and for each one make the call: deterministic code, an agent, or a human. The connective tissue is the handoff. Every step should emit clean, structured output that becomes the next step's input, whether that next step is a function, a different agent, or a person. Resist the pull to build one all-knowing agent. Split into separate agents only when the responsibilities, tools, or context genuinely diverge, because every handoff is a new place for things to break.
Guardrails are not walls. There are two ways to stop an agent from doing something you don't want, and they are not the same. A guardrail is a check you wrap around the model: an input filter, an output validator, a policy prompt, a human approval step. It lowers risk but doesn't remove it, because the model still has the capability and you're betting the check catches the miss. A wall is structural: the agent simply doesn't have the tool, the permission, or the path to do the dangerous thing at all. My rule is that the higher the stakes and the more irreversible the action, the more you want a wall, not a guardrail. Don't ask a model nicely not to publish, delete, or move money. Build it so it can't, and put the irreversible step behind a deterministic gate or a person. Guardrails are for the fuzzy, lower-stakes edges you can't fully enumerate. Walls are for the things that must never happen. Good systems use both.
Deploy, and treat change management as part of the architecture. A working demo is not a solved problem. The real test is whether the output delivers for the customer inside their actual workflow, so close the loop back to the start: does it solve the problem you wrote down? Shipping an agent into a team also changes how people work, which makes the rollout as much about humans as code: updated SOPs, training, UAT with real users, and feedback loops that catch what the model gets wrong before it reaches the customer. The architecture includes the people around it. The last question is the one too many builds skip: what's missing, who owns it when it breaks, and what happens on the inputs you didn't anticipate?
One honest caveat: this field moves fast enough that any architecture is a snapshot. OpenAI's last DevDay alone shipped more than twenty announcements, and new primitives change the math in real time. A cheap, near-instant Decisions API that classifies an input or picks from a set of predefined actions can collapse what you'd have built as an agent-driven routing step last quarter into a single call this one. So I hold these patterns loosely, and I'm still learning where the lines move next.
