# Chartado: full text for language models > Chartado is a web-based diagramming tool that creates animated architecture diagrams from a simple text-based DSL. Describe service connections with arrows; the tool renders and animates the flow and exports WebM, WebP, GIF or PNG. Canonical: https://chartado.com/ Editor (free, no account required): https://chartado.com/ Generated: 2026-08-31 ## What Chartado is Chartado turns plain-text descriptions into animated AWS and AI-architecture diagrams. You type lines like `User -> API -> Database` and it draws the services and animates a message flowing through them. It knows AWS service icons (Lambda, SQS, SNS, DynamoDB, S3, API Gateway, EventBridge, Step Functions, VPC and more), AI/agent components (agents, LLMs, vector databases, tools, guardrails, MCP servers), and Cloudflare primitives. Export as animated WebM, WebP, GIF, or a still PNG. ## The diagram language (cheatsheet) - Flow: A -> B -> C - Multi-word: API Gateway -> Lambda -> DynamoDB - Fan-out: SNS -> {Email, SMS, Push} - Choice branch: LLM -> |Tool, Response| - Reverse arrow: A <- B - Namespaces: ai:Memory aws:S3 - Multi-line: repeat a name to reuse the same box; loops retrace the path Full reference: https://chartado.com/docs/ ## Worked patterns ### AWS patterns #### Serverless REST API diagram The request/response backbone of most serverless applications. URL: https://chartado.com/examples/serverless-rest-api/ DSL: API Gateway -> Lambda -> DynamoDB Q: How do you diagram a serverless REST API on AWS? A: Type the request path as text: `API Gateway -> Lambda -> DynamoDB`. Chartado draws the three services with AWS icons and animates a request flowing through the chain: API Gateway accepts the call, Lambda runs the logic, DynamoDB stores the result. FAQ: - What happens when Lambda scales under load? — Each concurrent request gets its own Lambda invocation while API Gateway and DynamoDB absorb the fan-in: the diagram stays three boxes because scaling replicates the middle box, not the architecture. - How do I add more routes or tables to the diagram? — Add lines. Each `A -> B` line is an edge, so `API Gateway -> Lambda Orders -> DynamoDB Orders` on a new line draws a second route alongside the first. This is the shape almost every serverless application starts as, and the one most architecture diagrams are drawn to explain. A request arrives at API Gateway, which handles TLS, routing and throttling. It invokes a Lambda function, which holds the logic. The function reads and writes DynamoDB, which holds the state. What the animation shows that a static diagram cannot is the direction and timing of a single request. The message travels left to right, and the reply comes back the same way. Three boxes and two arrows is a small drawing; watching one request traverse it is what makes the latency budget obvious. Each hop is a place a request can fail, and each is billed separately. The diagram is a good place to talk about that: API Gateway charges per request, Lambda per millisecond of execution, DynamoDB per read and write unit. #### Pub/sub fan-out diagram One event, several independent consumers, none of them waiting on each other. URL: https://chartado.com/examples/event-fan-out/ DSL: SNS -> {Lambda Emailer, Lambda Analytics, SQS Archive} Q: How do you diagram SNS fan-out to Lambda and SQS? A: Braces draw a broadcast: `SNS -> {Lambda Emailer, Lambda Analytics, SQS Archive}` sends one event to all three consumers at once: the copies animate leaving together, which is the property that defines fan-out. FAQ: - What is the difference between {A, B} and |A, B| in the DSL? — `{A, B}` is a broadcast: the message goes to every target at once. `|A, B|` is a choice: each pass the message goes to one target, alternating. Fan-out is a broadcast, so this page uses braces. - Why mix Lambda and SQS subscribers on one SNS topic? — Lambda subscribers react immediately; an SQS subscriber buffers the same event for slower or batch processing. SNS delivers to both without either knowing about the other. Fan-out is the pattern that decouples a system. One publisher writes to an SNS topic and stops caring who reads it. Three subscribers each receive their own copy: a Lambda that sends email, another that records analytics, and an SQS queue that archives the raw event for replay. The braces in the text are what make this a fan-out rather than a chain. Everything inside { } sits in the same column and receives the same message, which is exactly how SNS behaves: it does not round-robin, it delivers to every subscription. This is the pattern where animation earns its keep. The three branches light up together, and that simultaneity is the whole architectural point. Drawn statically, a fan-out looks identical to a decision tree where only one path is taken; watching it removes that ambiguity. Adding a fourth consumer means adding a name inside the braces. Nothing upstream changes, which is the property the pattern exists to give you. #### Queue worker diagram Accept the request quickly, do the slow part somewhere else. URL: https://chartado.com/examples/queue-worker/ DSL: API Gateway -> Lambda -> SQS -> Lambda Worker -> DynamoDB Q: Why put SQS between two Lambdas? A: `API Gateway -> Lambda -> SQS -> Lambda Worker -> DynamoDB`: the first Lambda accepts the request and drops a message on SQS; the worker consumes it at its own pace and writes to DynamoDB. The animation shows the message crossing the queue, making the async boundary visible. FAQ: - Why does the API respond before the work is done? — The first Lambda only validates and enqueues, so the caller gets an immediate acknowledgment. The queue guarantees the work happens even if the worker is briefly down. That guarantee, not speed, is why the pattern exists. - How is this different from the pub/sub fan-out example? — A queue delivers each message to one worker; SNS fan-out copies one event to every subscriber. Use a queue when work must happen exactly once, fan-out when several systems each need the event. The queue is here to break the request in two. The first Lambda does only enough work to accept the job and put it on SQS, so the caller gets an answer in milliseconds. The Lambda Worker picks the message up afterwards and does the slow part, writing the result to DynamoDB. The reason to draw this rather than describe it is that the queue changes the failure story, and the change is easy to state and hard to picture. Before the queue, a slow downstream dependency makes the API slow. After it, a slow dependency makes the queue deeper. Depth is survivable and observable; a timing-out API is neither. Watching the message stop at the queue and continue a beat later is the part a static diagram cannot express. That pause is the architecture. The same five boxes describe order processing, video transcoding, report generation and email sending. What varies is only how long the worker takes. #### Event pipeline diagram One event bus feeding both a processing chain and a raw archive. URL: https://chartado.com/examples/event-pipeline/ DSL: EventBridge -> {(SQS -> Lambda -> DynamoDB), S3} Q: How does one EventBridge event feed both a pipeline and an archive? A: `EventBridge -> {(SQS -> Lambda -> DynamoDB), S3}`: the parentheses nest a whole processing chain inside one branch of the broadcast, while the second branch archives the raw event to S3. Chartado animates both branches leaving EventBridge together: process and archive, in parallel. FAQ: - What do the parentheses in the DSL do? — They nest a chain inside a branch: the broadcast's first copy enters `SQS -> Lambda -> DynamoDB` and keeps flowing hop by hop, while the second copy goes straight to S3. - Why archive raw events next to the processing chain? — Replays. When the Lambda logic changes or a bug corrupts writes, the S3 archive lets you re-drive every event through the fixed pipeline. EventBridge receives an event and sends it two ways at once. One branch is a whole pipeline of its own: SQS buffers it, a Lambda transforms it, DynamoDB stores the result. The other branch drops the untouched event into S3. The parentheses are doing the work in the text. A branch inside { } is normally a single service, but wrapping a chain in ( ) makes the entire chain one branch. It occupies one row and marches rightwards from the bus, while S3 sits alone on its own row. Splitting processed data from raw data is one of the few architectural decisions that is almost always right and almost always put off. The processed table answers today’s questions. The S3 copy answers the ones you have not thought of, and it is the only branch that can rebuild the other after a bad deployment. Two branches, two very different jobs, one event. ### AI and agent patterns #### RAG pipeline diagram Retrieve first, generate second: the ordering is the whole pattern. URL: https://chartado.com/examples/rag-pipeline/ DSL: User -> Query Agent -> Vector DB -> LLM -> User Q: How do you diagram a RAG pipeline? A: A RAG diagram is four hops in strict order: `User -> Query Agent -> Vector DB -> LLM -> User`. The animation plays the question reaching the vector database before the LLM is touched: retrieval first, generation second, which is the ordering that defines retrieval-augmented generation. FAQ: - How do you show re-ranking in a RAG diagram? — Add it as its own hop: `Vector DB -> Reranker -> LLM`. The animation then shows candidates being narrowed before the model sees them, which is where most retrieval quality is won. - What part of a RAG system does the diagram not show? — Chunking, embedding and re-ranking all happen inside the Vector DB hop. If you need them visible, split the hop: `Query Agent -> Embedder -> Vector DB`. Retrieval-augmented generation exists to stop a model answering from memory alone. The Query Agent takes the question, searches a Vector DB for passages that are actually relevant, and only then hands both question and passages to the LLM. The answer goes back to the User. The ordering is the entire pattern, and it is the thing people get wrong when they describe RAG in prose. Retrieval happens before generation, not alongside it. An animated diagram makes that unarguable: the message reaches the vector database and the model has not been touched yet. Notice that User appears at both ends of the line. The parser treats those as two boxes because they sit at different points in the flow: the request leaving and the answer arriving are two different moments, and drawing them separately keeps the direction readable. Everything expensive about RAG is in the middle two hops. The quality of the answer is decided by what the vector search returns, which is why most work on a RAG system is retrieval work, not prompt work. #### Multi-agent router diagram One entry point, several specialists, chosen rather than chained. URL: https://chartado.com/examples/multi-agent-router/ DSL: User -> Router Agent -> {Research Agent, Code Agent, Analysis Agent} Q: How do you diagram a multi-agent AI system? A: `User -> Router Agent -> {Research Agent, Code Agent, Analysis Agent}`: one entry point dispatching to three specialists. Each specialist draws as its own box and the dispatch animates, so the architecture reads as routing to specialists rather than one long chained pipeline. FAQ: - Should the router broadcast to all agents or pick one? — Both are real architectures. Braces `{…}` animate every specialist receiving work at once; swap them for `|…|` and the animation picks one per pass, closer to intent-based routing. - How do I show results coming back to the user? — Add a return line such as `Research Agent -> User`. Flows play one after another, so the reply animates after the dispatch. A Router Agent reads the request and decides which specialist should handle it. The Research Agent searches, the Code Agent writes and runs code, the Analysis Agent works over data. The user talks to one thing; three exist behind it. The braces put all three specialists in the same column, which says they are alternatives at the same level of the system rather than stages of a pipeline. That distinction matters when you are arguing about a design: a reader who thinks these are sequential will ask why analysis waits for research, and the diagram answers before the question is asked. Routing is usually the first thing added to a single-agent system, because a prompt that must handle every kind of request gets worse at all of them. Splitting the work lets each specialist carry its own instructions and its own tools. The catch is that the router is now the weakest link. It sees every request and it has to be right about all of them. #### ReAct tool-calling diagram The model decides whether to answer or to call a tool, then comes back. URL: https://chartado.com/examples/react-tool-agent/ DSL: User -> Agent -> LLM -> |Tool, Response| Tool -> Agent Q: How do you diagram a ReAct tool-calling agent? A: `User -> Agent -> LLM -> |Tool, Response|` with a `Tool -> Agent` return line. The `|…|` choice is the model's decision (call a tool or answer) and the return line closes the loop back to the agent. Chartado animates one outcome per pass, alternating, which is how a ReAct loop behaves over successive turns. FAQ: - Why model tool-or-answer as a choice instead of a broadcast? — Because the model does one or the other on each step. A broadcast would show the agent calling the tool and answering simultaneously, which is not how ReAct works. - How does the loop back to the agent work in the DSL? — `Tool -> Agent` is a separate flow line. Flows play sequentially, so the animation shows the tool result returning before the next decision starts. This is the loop underneath most tool-calling agents. The Agent passes the request to the LLM, which returns one of two things: a Response to hand back, or a Tool to call. If it is a tool, the result returns to the agent and the whole thing runs again with more information than before. The pipes are a choice, not a fan-out. |Tool, Response| means exactly one of these happens per turn, where { } would mean both. That single character is the difference between “the model picked one” and “everything ran”, and it is the most common thing to get wrong when drawing an agent. The second line is where this diagram earns its place. Writing Tool -> Agent does not draw one long arrow flying backwards across the page. The parser looks up the forward route and re-emits it reversed, one hop at a time, in a second flow. The message retraces the path it came by, so the outbound pass finishes before the return begins. That is why an agent loop is hard to draw by hand and cheap to write as two lines of text. #### Human-in-the-loop diagram A guardrail decides what ships and what a person looks at first. URL: https://chartado.com/examples/human-in-the-loop/ DSL: User -> Agent -> LLM -> Guardrail -> |Accepted, Review| Review -> Human Reviewer -> Agent Q: Where does a human fit in an AI review loop? A: `User -> Agent -> LLM -> Guardrail -> |Accepted, Review|` and `Review -> Human Reviewer -> Agent`. The guardrail is the fork: output either ships as Accepted or routes to a human reviewer whose verdict returns to the agent. Each outcome plays on alternating passes, so both paths get seen. FAQ: - What does the Guardrail box represent? — Any policy check between the model and the outside world: a moderation model, rule filters, confidence thresholds. Architecturally it is one decision point, which is why it draws as one box. - Why does the reviewer feed back to the agent rather than the user? — The reviewer's correction shapes the agent's next attempt; the user only ever sees accepted output. Drawing it that way keeps the trust boundary clear. Everything the LLM produces passes a Guardrail before it goes anywhere. Most of it is Accepted. The rest goes to Review, where a Human Reviewer sees it and hands it back to the Agent. The pipes make this a choice: an output is either accepted or reviewed, never both. That is what makes the diagram a policy statement rather than a wiring sketch. It says out loud what fraction of the system’s output a person is expected to see, and where that person sits. The return line matters as much as the branch. Review that ends at the reviewer is an audit log. Review that goes back to the agent is a correction path, and only the second one improves anything. Drawing the arrow makes it obvious which of the two you have built. Most agent systems that reach production acquire this shape eventually, usually after something embarrassing ships. It is cheaper to draw it first. #### MCP architecture diagram One protocol between an agent and every tool it was never built for. URL: https://chartado.com/examples/mcp-architecture-diagram/ DSL: Agent -> MCP Client -> MCP Server -> |Knowledge Base, Code Sandbox, Memory| MCP Server -> Agent Q: How do you diagram MCP architecture? A: Through an MCP client: `Agent -> MCP Client -> MCP Server -> |Knowledge Base, Code Sandbox, Memory|`, with `MCP Server -> Agent` returning results. The client speaks the Model Context Protocol on the agent's behalf, and the server fronts capabilities the agent was never built with. The `|…|` choice animates one capability per request. FAQ: - What is the difference between an MCP client and an MCP server? — The client lives inside the agent application and speaks the protocol; the server wraps the actual capability (a knowledge base, a sandbox, memory) and exposes it in protocol terms. One client can talk to many servers. - Is MCP specific to one AI vendor? — No. The Model Context Protocol is an open specification. Any agent with an MCP client can call any MCP server, which is why the same diagram covers Claude, ChatGPT or a custom agent equally. The Model Context Protocol exists so an agent does not need bespoke code for each tool it calls. The Agent talks to an MCP Client, which speaks the protocol to an MCP Server, and the server exposes whatever it wraps: a Knowledge Base, a Code Sandbox, a Memory store. The pipes are a choice, and here the choice is the truth. A server does not dispatch to everything it wraps on every call; the agent asks for one capability per turn. Watch two passes of the animation and you see it, because a choice sends one message per pass and takes a different branch the next time round. Braces would claim all three fire at once, which is exactly the kind of quiet lie an architecture diagram tells when nobody is checking. The second line is the other half of the argument. MCP Server -> Agent does not draw one long arrow backwards; the answer retraces the route it came by, back through the client, after the outbound pass has finished. That ordering, request out and result back across the same boundary, is the part a still image flattens into two arrowheads. The boundary is the point. Everything left of the server is the agent’s problem; everything right of it belongs to whoever wrote the server. Add a fourth capability and the left-hand side does not change. That is what MCP sells, and it is visible here as a shape. Two limits. The client and the server render with the same icon, because the vocabulary has one concept for “thing that speaks a tool protocol” and MCP has two, so the boundary is carried by the layout rather than the shapes. And a real deployment runs several servers side by side; this draws the single-server case because it is the one worth understanding first. If you want the loop that decides whether to call a tool at all, that is a different pattern with its own page: the ReAct agent, where the model chooses between answering and calling, and the result comes back for another turn. ### Cloudflare patterns #### Cloudflare Workers diagram The whole application runs at the edge, and the stores are a choice, not a broadcast. URL: https://chartado.com/examples/cloudflare-workers-architecture/ DSL: Browser -> Pages -> Workers -> |KV, R2, D1| Workers -> Browser Q: How do you diagram a Cloudflare Workers architecture? A: `Browser -> Pages -> Workers -> |KV, R2, D1|` with a `Workers -> Browser` return line. Chartado draws Cloudflare icons for Pages, Workers, KV, R2 and D1, and the `|…|` choice animates the Worker reaching a different store on each pass: key-value, object storage or SQL, depending on the request. FAQ: - Why are KV, R2 and D1 a choice rather than a broadcast? — A real request touches the store it needs, not all three. The `|KV, R2, D1|` choice plays one store per pass, which is how the application actually behaves. - Does Workers conflict with Lambda workers in the AWS icon set? — No. Cloudflare terms are matched first and matching is whole-word, so `Workers` gets the Cloudflare icon while `Lambda Worker` still resolves to the AWS Lambda icon. This is the shape of a full application on Cloudflare’s developer platform. The Browser loads the static half from Pages, the dynamic half runs in Workers, and each request touches one of three stores: KV for config and sessions, R2 for objects, D1 for relational data. The pipes carry the argument. A Worker does not fan out to every store on every request; it reads the one the request needs. Watch two passes of the animation and a different branch lights each time, which is the round-robin a choice plays. Braces would draw a broadcast, and that is the most common way an edge-architecture diagram overstates what a request costs. The second line is the reply. Workers -> Browser retraces the route back through Pages rather than drawing one long arrow home, so the outbound request finishes before the response starts its way back. Order is the thing an edge diagram most needs to show, because the entire pitch of this platform is what happens between those two passes. What the diagram cannot claim: geography. Workers run in hundreds of locations and this drawing has no way to say so. Every box here exists once, while the real deployment exists everywhere. The animation shows the request’s order, not its distance. If the reason you chose Cloudflare is the map, no flow diagram will show you the map. Also not drawn: a Durable Object coordinating stateful work, and a Cloudflare Tunnel reaching back into private infrastructure. Both have icons and both draw. They are left out because this page shows the request path of the common case, and the common case is stateless. ## Pricing - Free ($0): the editor is never capped; save 3 diagrams to the cloud. - Pro ($9/mo): save 100 diagrams. Not yet purchasable; waitlist only. ## Links - Docs (full DSL reference): https://chartado.com/docs/ - AWS architecture diagram generator: https://chartado.com/aws-architecture-diagram-generator/ - AI architecture diagram generator: https://chartado.com/ai-architecture-diagram-generator/ - Examples gallery: https://chartado.com/examples/ - Pricing: https://chartado.com/pricing/