About agentic-system.design

agentic-system.design is a field guide for architects and senior engineers building production agentic systems.

The project studies how different ecosystems address recurring engineering problems: how they frame them, where they place responsibility, which design choices they make, and what trade-offs shape those choices.

The goal is to help engineers apply what they learn in one ecosystem when evaluating another, while separating what transfers across ecosystems from what depends on a particular implementation.

Learn an ecosystem. Understand its choices. Compare approaches. Transfer what you know. Generalize what repeats.

Why this exists

Agentic System Design is still an emerging engineering discipline. Many of its underlying engineering problems are familiar, but different ecosystems distribute responsibility for solving them across application code, frameworks, platforms, and protocols.

A capability that one team implements in application code may already be built into a framework elsewhere, exposed as a managed platform feature in another ecosystem, or standardized through a protocol.

Those responsibility boundaries also move over time. What teams build themselves today can become a framework capability tomorrow, and later move into managed infrastructure or an open standard.

Terminology adds another source of ambiguity. Words such as memory, session, runtime, gateway, and even agent can refer to different abstractions across ecosystems and imply different responsibility boundaries.

The challenge is to see the engineering problem behind the current tooling and terminology. That means understanding which decisions and trade-offs remain useful across ecosystems, and which are specific to the abstractions available today.

Without that distinction, teams can end up treating ecosystem-specific abstractions as if they were universal architectural constraints.

How we study

agentic-system.design studies each ecosystem on its own terms before comparing the engineering problems and decisions that recur across them.

We first look at the terminology an ecosystem uses, the abstractions it provides, where it places responsibility, and the constraints and trade-offs behind those choices. We avoid translating everything into a shared model before understanding why those choices were made.

Comparison focuses on engineering decisions rather than product names or feature lists. Differences between approaches can reveal distinct trust models, operational requirements, platform assumptions, or responsibility boundaries. Understanding why those differences exist helps separate implementation-specific choices from ideas that may remain useful elsewhere.

What we learn in one ecosystem should help us evaluate another without assuming that the same abstraction or implementation will carry over. What transfers may be a design decision, a trade-off, a failure mode, or a better way to frame the problem.

We name broader patterns only when the same engineering problem and similar reasoning appear across multiple ecosystems. Not every comparison needs to produce one common answer. Different constraints can justify different architectural choices.

What we're studying now

We currently study five ecosystems through professional certifications.

Certifications provide a structured view of what the organizations behind those ecosystems expect qualified practitioners to understand, decide, and apply. They also show how each ecosystem frames the engineering problems within that scope.

A certification is a lens into an ecosystem, not the ecosystem itself.

An exam blueprint tells us what an organization chooses to assess. Product documentation, specifications, reference architectures, and other primary sources tell us how the underlying technology works and provide evidence for broader architectural conclusions.

The certification guides also serve as practical learning paths for engineers preparing for the corresponding exams.

About the editor

agentic-system.design was founded and is edited by Nikita Galkin, a Cloud Architect and Fractional CTO, Google Developer Expert, and AWS Community Builder.

AI agents are part of the research and editorial process. For a project about agentic systems, it would be a little strange not to use them.

They help with research, drafting, comparison, and review. Nikita remains responsible for what is published, the evidence behind it, and the distinction between documented fact, interpretation, and broader conclusions.

Follow the project

Subscribe for new guides, ecosystem studies, and updates from agentic‑system.design.