If you’ve shipped more than one AI agent to production, you’ve probably noticed something: the architecture diagrams on day one and day ninety look almost nothing alike. Day one is a single endpoint that wraps a model call. Day ninety is a sprawl of retry loops, memory stores, tool wrappers, observability hooks, and prompt-versioning hacks duct-taped together by whoever was on call at 3 a.m.

After eighteen months of watching teams iterate on this exact arc, we’ve come to believe the same three-layer pattern always emerges. The teams that get there fast win. The teams that get there slow burn out and blame the model.

Layer 1: The agent runtime

This is the layer that takes a goal and a context, decides what to do next, and either calls a tool or produces a response. It is not just a model call. It’s a control loop with budgets (tokens, tool calls, wall-clock time), step-level fallbacks, and structured outputs.

Common mistake: pushing all the logic into the prompt. The prompt is one input to this layer, not the layer itself. Anything stateful, anything that needs to be debugged, anything that needs metrics — that belongs in the runtime, not the prompt.

Layer 2: The tool layer

Tools are how the agent affects the outside world. The hard parts here are not the tools themselves; the hard parts are the contracts. Each tool needs a schema the model can target accurately, an executor that handles transient failures cleanly, and a result format that’s compact enough to fit back into the next agent step without blowing the context window.

We’ve seen teams build their tool layer as a thin wrapper around their existing API surface. That works for two weeks. Then they discover that the schemas LLMs work well with are not the schemas humans wrote for REST endpoints in 2018, and they have to redo the whole thing.

Layer 3: Memory

Memory is where production agents diverge from demos most dramatically. A demo can fit everything in the prompt. A production agent supporting thousands of conversations cannot.

The memory layer needs at least three scopes: per-session (this conversation), per-user (everything we know about this person), and global (organization-level facts). Each scope has a different lifetime, different retrieval strategy, and different write semantics. Treating them as one big bucket is the most common architectural mistake we see.

If your memory layer is “stuff the last 20 messages into the prompt,” you have a demo, not a system. The day a customer comes back after a week and asks “remember when we…” is the day you find out.

Why we built Korelos around this

Every agent we’ve helped teams ship needed all three layers. Every team that tried to skip one paid for it later. Korelos exists because we got tired of watching smart engineers rebuild the same scaffolding for the fifth time. The runtime, tool layer, and memory layer are the platform — what you bring is the goal.