Jordi Garcia Castillon

Posted on Sep 7

AI Graph Studio: Engineering Agentic AI as Explicit Graphs

#ai #agents #architecture #engineering

Abstract

Artificial intelligence is moving beyond the conventional prompt → response interaction model. Production-grade agentic systems increasingly combine language models with tools, retrieval, memory, persistent state, conditional routing, evaluators, guardrails, human approval gates, retries, parallel execution and multi-agent coordination.

This transition changes the engineering problem. Prompt quality remains important, but the behavior of an advanced AI system is increasingly determined by its execution topology: which components run, in what order, under which conditions, with what state, privileges, budgets, termination criteria and validation mechanisms.

AI Graph Studio is an open-source, vendor-neutral visual workbench for designing, documenting, analyzing and reasoning about these architectures as explicit graphs. It is designed for AI architects, engineers, security professionals, researchers, consultants and organizations that need a rigorous way to represent agentic workflows before or alongside implementation.

The application is free to use without imposed usage limits and its source code is released under the MIT License.

Live application: https://aigraphstudio.jordigarcia.eu/
Source repository: https://github.com/gcjordi/aigraphstudio

1. The Architectural Shift: From Model Calls to AI Systems

A traditional assistant interaction can be simplified as:

Input → Prompt / Context → Model → Output

That abstraction remains useful, but it is insufficient for many contemporary AI applications. A more realistic agentic architecture may look like:

Input
  ↓
Router
  ├──→ Retrieval → Specialist Agent ──┐
  ├──→ Tool/API → Execution Agent ────┼→ Evaluator → Decision
  └──→ Memory → Context Agent ────────┘                  │
                                                         ├→ Output
                                                         └→ Retry / Replan

The important change is not merely that the underlying model is more capable. The system surrounding the model has become a first-class engineering concern.

An agentic system may need to classify a request, retrieve evidence, choose a model, invoke tools, preserve state, coordinate specialized agents, evaluate intermediate results, branch according to confidence, retry failed operations, request human authorization and determine when execution should terminate.

The model is therefore only one component in a larger computational system. Observable behavior emerges from the interaction of:

models and prompts;
tools and APIs;
retrieval and knowledge sources;
memory and state;
routing and control logic;
evaluators and critics;
guardrails and policies;
human authorization;
execution budgets;
and termination conditions.

AI Graph Studio was created to make this architecture explicit.

2. What AI Graph Studio Represents

AI Graph Studio is not intended to be a generic flowchart editor with AI-themed labels. Its conceptual vocabulary maps directly to recurring primitives in agentic AI engineering.

Architectures can be constructed using elements such as:

Start / Input
Prompt
Agent / LLM
Router / Decision
Tool / API
Code / Function
Retrieval / RAG
Knowledge / Memory
Parallel Split
Merge / Aggregator
Human Approval
Loop / Retry
Evaluator / Critic
Guardrail / Policy
Output

These nodes are connected through directed edges that describe execution flow and, where appropriate, conditional transitions.

This provides a common architectural language for systems that might ultimately be implemented using very different frameworks, models, cloud providers or local infrastructure.

3. Agentic Workflows as Directed Graphs

At its simplest, an AI workflow can be represented as a directed graph:

[
G = (V, E)
]

where (V) is the set of computational or control nodes and (E) is the set of directed transitions between them.

For an agentic architecture, the vertices are semantically typed. A node can be conceptualized as:

[
v_i = (t_i, c_i, m_i)
]

where:

(t_i) is the node type;
(c_i) is its configuration;
(m_i) is associated metadata.

An edge can similarly be modeled as:

[
e_{ij} = (v_i, v_j, \gamma_{ij})
]

where (\gamma_{ij}) is an optional transition condition.

The graph can therefore encode decisions such as:

Evaluator
   ├── score ≥ threshold → Accept
   └── score < threshold → Retry

This distinction matters. A useful agent graph does not merely show which components exist; it represents possible execution trajectories through the system.

Once loops, branches, failure paths, approvals and conditional tool use are involved, architecture becomes inseparable from control flow.

4. Loops as an Engineering Primitive

Iterative execution is one of the characteristic structures of agentic systems.

A generic state transition can be expressed as:

[
S_{t+1} = F(S_t, O_t, C_t)
]

where (S_t) is the current state, (O_t) is an observation or intermediate result, (C_t) is contextual information, and (F) determines the next state.

A common architecture is:

Plan
  ↓
Execute
  ↓
Observe
  ↓
Evaluate
  ↓
Accept? ── Yes → Finish
  │
  No
  ↓
Replan
  └────────────→ Execute

Loops enable revision and adaptation, but they also create operational risk. Poorly constrained loops can produce excessive model calls, runaway token consumption, repeated external actions, escalating API cost, latency amplification or effectively non-terminating execution.

A robust loop should therefore have explicit termination logic. For example:

[
stop =
(i \geq i_{\max})
\lor
(Q(output) \geq au)
\lor
(B \leq 0)
]

where (i_{\max}) is a maximum iteration count, (Q) is an evaluation function, ( au) is an acceptance threshold and (B) is the remaining execution budget.

Making loops visually explicit is valuable because architectural defects can be identified before they become runtime incidents.

5. Routing, Specialization and Model Tiering

A well-designed agentic system does not necessarily send every task through the same model or workflow.

A router can select an execution path according to task characteristics:

Request
   ↓
Router
   ├── Simple → Deterministic Function
   ├── Knowledge → Retrieval + LLM
   ├── Complex → Reasoning Agent
   └── Sensitive → Human Approval

Formally:

[
R(x, s)
ightarrow p_k
]

where (x) is the input, (s) is current state and (p_k) is the selected path.

This supports a fundamental engineering principle: use the least complex mechanism that can reliably solve the current subproblem.

A deterministic transformation does not automatically require an LLM. A lightweight model does not automatically require replacement by a frontier model. Previously validated state should not necessarily trigger another retrieval operation.

Graph-level representation makes these choices inspectable and exposes unnecessary computational complexity.

6. Multi-Agent Topologies

Multi-agent architectures are naturally graph-shaped.

                     ┌→ Research Agent ─────┐
User → Coordinator ──┼→ Security Agent ─────┼→ Synthesis → Evaluator
                     └→ Domain Agent ───────┘

This representation forces important design questions into the open:

Which agent owns orchestration?
Which agents can execute independently?
What state is shared?
What context is private to each agent?
Which operations can run in parallel?
How are disagreements reconciled?
Which component determines completion?
What happens when a specialist fails?
Which outputs require evaluation?
Which actions require human authorization?

Without an explicit architecture, these decisions can disappear into framework configuration, application code and increasingly complicated prompts.

A graph provides a shared representation that can be discussed across engineering, security, governance and business teams.

7. Parallelism and Latency Topology

Agentic workflows can accumulate significant latency when independent operations are unnecessarily serialized.

For sequential operations:

[
T_{seq} = T_A + T_B + T_C
]

If the operations are independent and can execute concurrently:

[
T_{parallel} pprox \max(T_A, T_B, T_C) + T_{merge}
]

The corresponding topology is:

          ┌→ Agent A ─┐
Input → Split → Agent B ─┼→ Merge → Output
          └→ Agent C ─┘

The difference becomes substantial when each node represents a remote model call, retrieval system or external API.

Graph design is therefore also a mechanism for reasoning about latency propagation and concurrency.

8. Retrieval, Memory and State Are Different Problems

Retrieval, memory and state are often treated as interchangeable concepts, but they serve different architectural functions.

Retrieval

Retrieval obtains information relevant to the current execution:

Query → Retriever → Evidence → Model

Memory

Memory preserves information across interactions or execution stages:

Interaction → Memory Write
                 ↓
Future Run ← Memory Read

State

State represents the current condition of the workflow:

state = {
    current_step,
    decisions,
    intermediate_results,
    tool_outputs,
    retry_count,
    remaining_budget
}

These distinctions affect persistence, security, privacy, context size, reproducibility, failure recovery and observability.

Representing them explicitly helps prevent architecture from degenerating into an opaque accumulation of context.

9. Evaluation as Part of the Runtime Graph

Evaluation should not always be an external activity performed only after development. In robust agentic architectures, evaluation can become a runtime component.

An evaluator may be represented as:

[
E(y, r, c)
ightarrow (score, decision)
]

where (y) is a generated result, (r) is a rubric or requirement and (c) is relevant context.

The evaluator may determine whether to accept, regenerate, retrieve additional evidence, invoke another agent, escalate to a human or terminate execution.

Agent → Evaluator
           ├── Pass → Output
           ├── Revise → Agent
           └── Uncertain → Human Review

This transforms evaluation from an after-the-fact measurement process into part of the system's control architecture.

For consequential autonomous systems, that distinction is critical.

10. Guardrails, Policies and Human Authorization

Agentic autonomy introduces a security boundary between reasoning and action.

A model deciding that an operation should occur does not imply that the operation should automatically be permitted.

A more defensive architecture may look like:

Agent
  ↓
Policy / Guardrail
  ↓
Risk Classification
  ├── Low → Execute Tool
  ├── Medium → Additional Validation
  └── High → Human Approval

Human approval can be an explicit governance control before financial transactions, destructive operations, privileged infrastructure changes, external communications, publication, access-control modifications or sensitive data transfers.

A graph makes the location of these trust and authorization boundaries immediately visible.

11. From Diagramming to Architecture Linting

One of the central ideas behind AI Graph Studio is that an AI architecture should be analyzable, not merely drawable.

Once a workflow exists as a structured graph, static rules can inspect its topology. This creates an analogy with linters and static-analysis tools in conventional software engineering.

Examples of architectural findings include:

Unbounded loops

A retry or feedback cycle lacks an explicit stopping condition.

Missing evaluation

A consequential generation path reaches an output or action without validation.

Missing guardrails

A model reaches an external tool without an intervening policy or validation layer.

Missing human approval

A high-impact action can be performed autonomously where explicit authorization may be appropriate.

Excessive sequentiality

Independent model or tool calls are unnecessarily serialized.

Context duplication

Large equivalent contexts are repeatedly propagated through multiple nodes.

Inappropriate LLM usage

A probabilistic model is used for a deterministic task that could be implemented more reliably in code.

Excessive frontier-model usage

High-cost models are used throughout the graph where model tiering or deterministic components could satisfy some requirements.

Weak termination logic

A loop technically has an exit but relies on ambiguous or fragile convergence criteria.

The purpose is not to claim that architecture quality can be fully automated. Instead, analysis acts as an architectural review assistant, identifying structures that deserve expert attention.

12. Cost Is a Property of the Graph

LLM cost is often treated as a model-pricing problem. In practice, it is also an architectural property.

For one model call, a simplified cost function is:

[
C_{call} =
rac{T_{in}}{10^6}P_{in}
+
rac{T_{out}}{10^6}P_{out}
]

For an execution graph:

[
C_{run} = \sum_{i=1}^{n} f_i C_i
]

where (f_i) is the expected execution frequency of node (i).

For a loop:

[
C_{loop} = E[I] \cdot C_{iteration}
]

For conditional branches:

[
E[C] = \sum_{k=1}^{m} p_k C_k
]

where (p_k) is the probability that branch (k) executes.

This explains why apparently minor architectural choices can dominate operating cost. A model call placed inside a high-frequency loop has a completely different economic effect from the same call on an infrequent branch.

AI Graph Studio includes cost-estimation concepts with user-editable model pricing so that architecture can be evaluated without coupling the tool permanently to one provider's pricing model.

13. Simulation Before Deployment

A graph becomes significantly more useful when architects can ask:

What is likely to happen when this architecture executes?

AI Graph Studio includes simulation-oriented functionality for reasoning about quantities such as model calls, tokens, iterations, approximate cost and latency.

This is a design-time estimator, not a substitute for production telemetry or benchmarking.

Its purpose is to expose architectural consequences before implementation.

Consider:

Input → Agent → Critic → Retry → Agent

The visual structure appears small. But if the expected retry count is high, the effective number of model calls and generated tokens per request may be several times larger than a superficial inspection suggests.

Simulation connects topology with operational behavior.

14. Documentation and Portability

AI architecture is frequently fragmented across source code, framework configuration, prompts, cloud services, vector stores, API definitions, notebooks and internal documentation.

This creates architectural opacity.

A structured graph can serve as an intermediate representation between requirements and implementation.

AI Graph Studio supports export-oriented workflows including formats such as:

JSON
SVG
PNG
Markdown
Mermaid

Each serves a different purpose. JSON preserves structured project information; SVG and PNG support reports and presentations; Markdown supports engineering documentation; Mermaid provides a text-based representation suitable for repositories and technical documentation.

The goal is to make architecture portable, reviewable and communicable rather than trapping it in a proprietary workspace.

15. Vendor-Neutral by Design

Agentic AI systems increasingly combine technologies from multiple ecosystems: commercial model APIs, open-weight models, local inference, cloud services, custom tools, enterprise APIs, vector databases and internal data platforms.

AI Graph Studio therefore starts from architectural concepts rather than vendor-specific products.

The graph should be able to express:

Agent → Retrieval → Evaluator → Tool

before the implementation team decides which concrete model, vector database, orchestration framework or cloud platform will instantiate those roles.

This separation helps:

preserve architectural portability;
reduce design-layer vendor lock-in;
compare implementation alternatives;
survive provider changes;
and keep architecture reviews focused on behavior rather than branding.

16. Local-First, Client-Side Operation

AI Graph Studio is designed as a lightweight client-side web application.

Its core operation does not require a server-side AI service simply to construct a graph. The application can function without requiring user accounts, model API keys, an application database or a proprietary cloud workspace.

This is particularly relevant when diagrams contain sensitive information about internal systems, model topology, security controls, trust boundaries or enterprise workflows.

If an architecture-design operation does not require data to leave the browser, transmitting that data to a remote AI service should not be an architectural prerequisite.

The local-first approach therefore improves simplicity, portability and privacy simultaneously.

17. Lightweight Deployment Architecture

The application's architecture can be conceptualized as:

Browser
  │
  ├── User Interface
  ├── Graph / Canvas Engine
  ├── Node Model
  ├── Architecture Analyzer
  ├── Simulation Logic
  ├── Exporters
  ├── Local Persistence
  └── Internationalization

The project does not require a Node.js application server for ordinary runtime deployment, nor does its core functionality require a database or model API.

That makes self-hosting possible on conventional static or shared hosting infrastructure.

This simplicity is intentional. Infrastructure should be introduced because the product requires it, not because modern software convention makes it fashionable.

18. Security by Capability Reduction

Security is not only a matter of adding controls. It can also be improved by removing unnecessary capabilities.

A client-side architecture tool that does not need arbitrary network access, server-side processing or external model calls for its core operation can reduce its attack surface by avoiding them.

Conceptually:

[
AttackSurface \propto ExposedCapabilities
]

This is not a universal quantitative law, but it captures a useful security-engineering principle: every unnecessary capability creates another opportunity for misuse or failure.

Minimal runtime dependencies are therefore not merely a deployment convenience; they are part of the security posture.

19. The Graph as an Intermediate Representation

The most interesting long-term interpretation of AI Graph Studio is not as a drawing tool, but as a potential intermediate representation (IR) for AI architecture.

A future engineering pipeline can be conceptualized as:

Intent
  ↓
Visual Architecture
  ↓
Structured Graph
  ↓
Static Analysis
  ↓
Simulation
  ↓
Documentation
  ↓
Implementation
  ↓
Runtime Telemetry
  ↓
Architecture Refinement

Once architecture is represented structurally, future tooling can potentially use it to generate implementation skeletons, framework-specific configurations, observability requirements, architecture metrics, policy checks or comparisons between expected and observed execution paths.

The critical step is converting architecture from an image into machine-readable structure.

20. Agentic Architecture and Cognitive Security

As AI systems gain autonomy, security analysis must extend beyond conventional application security.

The attack surface increasingly includes the decision topology of the AI system itself.

Consider:

Untrusted Input
      ↓
     Agent
      ↓
External Tool

This small graph immediately raises questions:

Can untrusted content influence tool selection?
Does the agent have excessive privileges?
Is tool input validated?
Is there a policy boundary before execution?
Can retrieved content modify operational behavior?
Is human approval required?
Can the system recursively invoke itself?
What prevents repeated actions?
Which state persists after execution?

These are architectural questions before they become implementation vulnerabilities.

Graph modeling can therefore support threat modeling by making visible the boundaries between untrusted inputs, retrieval sources, memory, models, privileged tools, external APIs, approval gates and output channels.

21. Common Agentic AI Architecture Anti-Patterns

Graph-oriented analysis also makes recurring anti-patterns easier to identify.

The LLM-Everywhere Anti-Pattern

Every transformation is delegated to an LLM, including deterministic operations.

Result: higher cost, latency and nondeterminism.

Infinite Reflection

Agents repeatedly critique or regenerate results without robust convergence criteria.

Result: uncontrolled iterations and uncertain completion.

Context Avalanche

Large historical or retrieved contexts are repeatedly copied through the graph irrespective of relevance.

Result: token inflation, latency and reduced signal-to-noise ratio.

Frontier-Model Default

The most capable and expensive model is selected for every node.

Result: unnecessary operating cost and poor resource allocation.

Autonomous Privilege Path

Untrusted input can influence a model that directly reaches a consequential tool.

Result: an unsafe reasoning-to-action boundary.

Sequential Swarm

Independent agents execute serially.

Result: avoidable end-to-end latency.

Invisible State Machine

Critical workflow state is implicitly encoded in prompts or application logic rather than represented explicitly.

Result: reduced observability, reproducibility and debuggability.

Evaluation-Free Pipeline

Generated results reach users or external systems without systematic validation.

Result: weak runtime assurance.

Topology makes these patterns visible.

22. Intended Users

AI Graph Studio is designed for multiple roles:

AI architects can model orchestration, model, tool, retrieval and control topologies.

AI engineers can translate requirements into explicit execution graphs before implementation.

Security professionals can identify trust boundaries, privileged actions, uncontrolled loops and missing controls.

Researchers can represent experimental single-agent and multi-agent configurations.

Consultants can communicate architectures to clients using a consistent visual language.

Enterprise teams can document internal AI systems and discuss them across engineering, security, governance and management functions.

Educators can explain agentic architectures through explicit visual structures.

Governance and risk teams can identify where automated decisions, evaluations and human controls occur.

23. Open Source and the MIT License

AI Graph Studio is released under the MIT License.

The license permits broad reuse, modification, redistribution and commercial use, subject to preservation of the applicable copyright and license notice.

This choice is intentional.

An architecture tool becomes more valuable when organizations can self-host it, developers can extend it, researchers can experiment with it, companies can integrate it into internal processes and the community can contribute new architectural primitives and analysis rules.

The objective is to create an open foundation rather than another closed diagramming silo.

24. Community-Driven Evolution

Agentic AI architecture is evolving rapidly. New patterns are emerging around persistent agents, computer use, asynchronous workflows, hierarchical planning, distributed memory, event-driven execution, multi-agent negotiation, model ensembles, runtime verification and AI-specific security controls.

No fixed taxonomy can permanently capture this field.

An open-source architecture workbench can evolve alongside the engineering discipline.

Potential community contributions include:

new node types;
architecture-analysis rules;
graph templates;
export formats;
simulation models;
translations;
documentation;
accessibility improvements;
security enhancements;
performance improvements;
and reusable architecture patterns.

AI Graph Studio is therefore not only a tool but also a possible shared vocabulary for discussing how increasingly complex AI systems are constructed.

25. Toward Architecture-Aware AI Engineering

Software engineering developed explicit abstractions for source code, APIs, dependencies, infrastructure, testing, deployment and observability.

Agentic AI requires comparable abstractions for reasoning and action topology.

Engineers increasingly need to describe:

which models reason;
which components decide;
where knowledge enters;
where state persists;
where tools act;
where policies intervene;
where humans authorize;
where outputs are evaluated;
where loops terminate;
and how latency and cost propagate.

Once these properties are explicit, they can be inspected.

Once they can be inspected, they can be analyzed.

Once they can be analyzed, they can be optimized.

And once they can be versioned and communicated, agentic AI architecture becomes a more rigorous engineering discipline.

Conclusion

The transition from assistant-style AI toward agentic systems changes the unit of design.

The fundamental object is increasingly not a single prompt or even a single model call, but a graph of computational, cognitive and control components operating over state.

AI Graph Studio provides an open visual environment for working at that level. It combines graph-based architecture design with documentation, structural analysis, cost awareness, simulation and portable export mechanisms while remaining lightweight, vendor-neutral and suitable for self-hosting.

Its objective is straightforward:

Make agentic AI architectures easier to design, understand, inspect, communicate and improve.

AI systems are becoming architectures. Those architectures should be explicit.

Project Links

AI Graph Studio — Live application

https://aigraphstudio.jordigarcia.eu/

GitHub — Source code and community contributions

https://github.com/gcjordi/aigraphstudio

License

AI Graph Studio is distributed under the MIT License. Refer to the repository for the complete license terms.

AI Graph Studio — Visual architecture for agentic AI systems.