# agentic-ai-systems checks every pattern as a runnable file

> agentic-ai-systems teaches agent orchestration with a decision table, a taxonomy that separates code-controlled workflows from model-controlled agents, and a hard rule that subagents cannot spawn further subagents. Its distinguishing commitment is that each pattern is also a file that CI runs on every push, without an API key.

**ThibautMelen/agentic-ai-systems** — Agentic AI explained with chickens 🐔 every pattern a runnable, CI-checked file.

- Repository: https://github.com/ThibautMelen/agentic-ai-systems
- Stars: 317 · Forks: 35
- Language: Unknown
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/thibautmelen-agentic-ai-systems

## Every pattern is also a file that CI runs on every push

Most pattern catalogues are prose. This one ships each pattern as a runnable file that is checked in CI on every push, and the stated condition is that no API key is needed to do so.

The described origin of that discipline is specific: a repeated prompt graduates into a checked, runnable file, and every pattern in the repository works this way. So the catalogue is presented as the accumulated output of a process rather than as a set of examples written up after the fact.

The claim about scale is specific too. Three of the patterns in the real-world subsection run a real campaign daily, which is the difference between a demo that executes once and an example under continuous load.

Running a check without an API key is the constraint that makes this possible. Anything that needs a provider credential cannot be exercised in a public CI runner, so the patterns that get automated are the ones whose behaviour is deterministic: the decision logic, the routing, the structure of the prompt chain.

That boundary is worth understanding, because it means the CI check validates the pattern's shape rather than the quality of a model's response. The two are different claims and the repository is careful about which one it makes.

## The decision table names nine situations and maps each to one pattern

The selection mechanism is a table, not a diagram alone, and it pairs a situation with a pattern.

A simple single-step task goes to the baseline pattern. Sequential work of two to four steps goes to prompt chaining. Categorizing inputs goes to routing. Independent subtasks go to parallelization. Multiple specialists go to the orchestrator-workers pattern. Quality iteration goes to evaluator-optimizer. Open-ended problems with unknown steps go to the autonomous agent. Runs longer than ten minutes go to the multi-window context pattern.

The ninth entry is the odd one. Destructive operations route to a wizard, and the link points into an advanced section of the prompt chaining document rather than to a file of its own. So the table covers a case that the repository does not give a dedicated pattern for, which is a useful signal about where the boundary sits.

The diagram above the table encodes the same logic as a sequence of questions: is the task destructive, is it complex, are the steps predictable, and do you need specialists. Four questions, nine outcomes, and the destructive check comes first, which is the ordering you would want if an action cannot be undone.

## Code controls workflows and the model controls agents

The taxonomy diagram draws the distinction the whole repository is built on, and it is stated as a key distinction in prose as well.

Workflows have predefined paths, and code controls the flow. Agents decide their own path, and the model controls it. The diagram places the six workflow patterns in one group and the two agent patterns in another, with the flow running from code control through workflows to model control through agents.

That ordering matters as an argument. The repository is not presenting agents as the goal; it is presenting them as the option you reach when the preceding structure does not fit, because you cannot write the path in advance.

Inside the agent group the split is smaller than the workflow group. One entry is the autonomous agent itself, for open-ended problems. The other is a multi-window variant for cross-session state, explicitly labelled a variant rather than a separate pattern.

So the count is six workflow patterns and two agent entries, and the workflow set is numbered from zero through five, which suggests they were intended as a progression rather than a menu even before the decision table was added.

## A subagent cannot spawn another subagent

One rule gets a diagram of its own, labelled as the critical rule, and the diagram is mostly about a prohibition.

A user sends a request to a main agent. The main agent spawns subagents, collects their results, and returns a response. Between subagents there is a cross edge with a label saying a subagent cannot spawn another subagent.

So the hierarchy is exactly one level deep. A subagent may use tools and do work, but it cannot delegate further, which bounds the recursion that otherwise appears the moment you give a model a spawn capability.

The framing throughout is a hen with her chicks, and the rule is the biological one: the hen leads and gathers, the chicks do not form nests of their own. The visual language is doing real work here rather than being decoration, because the metaphor encodes the constraint.

If you are adapting these patterns, that edge is the thing to check first, since a harness that permits nested spawning will diverge from everything described in the rest of the repository.

## Implementation is four file conventions inside a Claude Code directory

The implementation section maps four components onto four paths, and the mapping is the entire specification.

A subagent is a Markdown file in an agents directory. A slash command is a Markdown file in a commands directory. A skill is a directory containing a skill file, using a nested layout with one file per skill. A hook is configured in the settings file.

Every one of them is Markdown or JSON inside a dot-prefixed directory, which means none of these components require code to be installed. You reproduce a pattern by writing a file with the right name in the right place.

That is also why the repository can claim to demonstrate patterns as code while shipping no runtime. What is checked in CI is files of this kind, not a Python package, which is consistent with the project being indexed with no detectable primary language.

The four components are presented as Claude Code components with their architecture, and the surrounding links point at documentation from the model provider and a research page on building effective agents, so the vocabulary is borrowed deliberately rather than invented.

## The repository is an Obsidian vault with a system file committed

The file list says as much about how this was written as the content does.

There is an Obsidian configuration directory committed at the root, which means the repository doubles as the author's note vault. There is also a macOS system file committed, which is the artifact every author has once deleted from a repository and then added back.

Neither is a functional problem, and both are consistent with a documentation project built inside a note-taking tool rather than assembled in an editor. The presence of the note configuration also suggests the diagrams and pages were authored as notes and then exported, which is why the top-level README carries several of the same diagrams the guide pages would.

There is a visual standards page in the reference section covering colors and emoji, plus a glossary running from A to Z. A colour and emoji specification is unusual in a technical repository and only makes sense when the same diagrams appear in several places and are meant to look identical in each.

Alongside them sit a selection guide, a use-cases directory described as six validated examples, a glossary, and a patterns-as-code section, which together are what a reader would use instead of reading the whole tree in order.

## Two of the top-level diagrams have truncated style lines

The four diagrams in the top-level README are written in Mermaid, with theme initialization blocks and class definitions, and two of them are cut off mid-token.

The quick decision flowchart ends with a class definition whose final declaration stops after a color property name with no value and no closing brace. The taxonomy diagram ends the same way, with a class definition line truncated after its first few characters.

A reader who pastes either block into a renderer gets a parse error or a silently ignored style, which for the decision diagram means the nodes render without the intended colour coding between decisions and outcomes.

This is a small thing, but it is worth naming in a repository whose whole argument is that documentation should be checked rather than trusted. The patterns are runnable files that CI executes; the diagrams that explain how to choose between them are not checked by anything.

The release history is short. Version 2.0.0 is labelled as the 2026 edition and was published in July 2026, with the last recorded push the following day. That edition added the dated map of what changed between 2025 and 2026, covering context engineering, the multi-agent debate, the standard stack of agent files, skills, and the protocol layer, and harness engineering.

## Conclusion

agentic-ai-systems suits someone choosing between orchestration patterns who wants the choice made on structure rather than taste, since the decision table names the nine situations and maps each to one pattern with a documented reason. It does not suit a reader looking for production code, because the repository is documentation and diagrams with no library to install. Before you rely on it, read the selection guide rather than the mindmap, and remember that the diagrams in the top-level README contain truncated style lines that will not render as written.

## FAQ

### What is an agentic system?

In this repository's taxonomy, workflows have predefined paths where code controls the flow, while agents decide their own path where the model controls it. The autonomous agent pattern is for open-ended problems, and the multi-window variant covers cross-session state.

### What are some examples of agentic AI systems?

The use-cases directory holds six validated examples, and three of the runnable patterns in the real-world subsection run a real campaign daily. The pattern set itself covers baseline, prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, and the autonomous agent.

### How do I choose a pattern in agentic-ai-systems?

Use the selection guide or the situation table: a simple one-step task to baseline, two to four sequential steps to chaining, categorizing inputs to routing, independent subtasks to parallelization, multiple specialists to orchestrator-workers, quality iteration to evaluator-optimizer, open-ended steps to the autonomous agent, destructive operations to the wizard, and runs over ten minutes to multi-window context.

### What is the critical rule about subagents in agentic-ai-systems?

The main agent spawns subagents and collects their results, and a subagent cannot spawn another subagent. The hierarchy is one level deep, which is drawn as an explicit prohibition edge in the diagram labelled the critical rule.

### Where are the Claude Code components documented in agentic-ai-systems?

As four file conventions: subagents as Markdown under the agents directory, slash commands under the commands directory, skills as one directory per skill containing a skill file, and hooks in the settings file. None of them requires installed code.

### How does agentic-ai-systems check its patterns?

The patterns-as-code section makes every pattern a runnable file that CI checks on every push, with no API key required. The described origin is a repeated prompt graduating into a checked, runnable file, and every pattern in the repository works that way.

## Sources

- [Issues](https://github.com/ThibautMelen/agentic-ai-systems/issues)
- [License: MIT](https://github.com/ThibautMelen/agentic-ai-systems/blob/main/LICENSE)
- [README](https://github.com/ThibautMelen/agentic-ai-systems/blob/main/README.md)
- [Releases](https://github.com/ThibautMelen/agentic-ai-systems/releases)
- [ThibautMelen/agentic-ai-systems on GitHub](https://github.com/ThibautMelen/agentic-ai-systems)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thibautmelen-agentic-ai-systems
