What You Will Learn

• Design verifiable agentic workflows using Atomic runtime primitives and gates
• Configure long-running sessions (npm install, herder multiplexer, hashline edits)
• Manage memory with sessions, file-based to-dos, verbatim compaction, and keep-context tags
• Build and orchestrate multi-agent teams with Intercom and intelligent handoffs
• Apply workflow patterns: fan-out, adversarial verification, classify-and-act, loop-until-done
• Author deterministic workflows in TypeScript with human-in-the-loop gates and multi-model orchestration

Study Guide

The Shift You Can't Ignore

Let's be real about where software engineering is headed. We've moved past the era of asking a chatbot to write a function and hoping for the best. That's table stakes now. The real shift is toward building systems that don't just generate code, but verify it, iterate on it, and manage entire projects over days without you holding its hand.
This course is about that shift. We're going deep into the world of agentic engineering, specifically using the Atomic runtime as our guide. This isn't a theoretical overview. We're talking about the actual primitives, the workflow designs, and the operational tactics that let you hand a complex, multi-day task to an autonomous system and trust that it will not only finish, but finish with evidence that it did the job right.
You're going to learn how to stop being a prompt writer and start being a system designer. We'll cover everything from setting up your environment for long-running sessions to building custom, verifiable workflows that encode your team's best practices. By the end, you'll understand why the future of engineering belongs to those who can define the process, not just execute the steps.

Why Verifiability Changes Everything

The biggest lie in AI-assisted coding is the model's own confidence. A model will tell you it's done, that the code is correct, that all tests pass. But it's often wrong. The entire philosophy behind a verifiable runtime is that you can't trust the model's self-assessment. You need external, deterministic proof.
Think about it like this: you wouldn't let a contractor tell you they finished building your house just because they said so. You'd inspect the foundation, check the wiring, and run the plumbing. A verifiable runtime does the same for code. It uses deterministic gates,like a test suite passing or a linter coming back clean,and LLM-as-a-judge reviewers to confirm the work is actually done.
This distinction is what scales. When you can prove a task is complete, you can let the system run for hours, days, or even weeks. You're not stuck in a loop of prompting and reviewing every single line. You're delegating a well-defined outcome to a system that can check its own work. That's the foundation we're building on.

Setting Up Your Command Center

Before we get into the fancy stuff, you need a solid foundation. The first step is installation, which is straightforward via npm. But the real game-changer for professional use is a terminal multiplexer like `herder`. This solves the "laptop lid closed" problem. You can SSH into a server, start an agent session, detach, and go live your life while the agent keeps working. When you come back, your session is still there, waiting for you. This is non-negotiable for any serious autonomous work.
Once you're in, the basic interactions are simple. You can reference files with an `@` tag to pull them into the model's context. You can run shell commands directly. And you can use `!!` to pipe the output of a command directly into the model's context, which is great for things like "Here's the directory listing, what do you see?"
One of the most powerful basics is hashline editing. Instead of asking the model to regenerate an entire file for a small change, you can target a specific line or block by its content hash. This is more efficient, uses less context, and is far less error-prone than rewriting whole sections. It's a small detail that makes a huge difference over a long session.

The Art of the Clarifying Question

One of the most underrated tools in the runtime is the ability for the agent to ask you questions. Before it embarks on a long, autonomous task, it can pause and present you with structured options. This isn't a bug; it's a critical feature. It's the difference between an agent that guesses at your intent and one that aligns with it.
Imagine you're asking it to scaffold a new service. You can instruct it to not write anything, but first ask you about your preferences. It might present a visual comparison of different architectural approaches, letting you tab through pros and cons before it writes a single line of code. This upfront alignment saves hours of potential rework down the line. It's a deliberate mechanism to prevent the agent from going off the rails for two days on a misunderstood requirement.

Managing Memory with Sessions and To-Dos

Context windows are finite, but your projects aren't. This is where session management and file-based to-dos come in. Think of sessions as the operating system's memory management. You have three core primitives: tree, fork, and clone. Treeing lets you go back to a previous message and branch from there, effectively undoing a path the agent went down. Forking creates a new session from your current context, which is useful for exploring an alternative approach without losing your main thread. Cloning makes a copy with an empty editor.
For long-term continuity, file-based to-dos are essential. You can tell the agent to create a plan with one to-do per function or module. These to-dos are stored on disk, so they survive context compaction. They act as the agent's external working memory. When the context gets pruned, the agent can read the to-do list and know exactly where it left off. This is what allows a single session to work coherently over many hours without getting lost.

Context Engineering: The Verbatim Compaction Difference

Most coding agents handle context overflow by summarizing the conversation. That's a terrible idea. A summary loses the critical details. If a failing test case is summarized, the model has to re-explore the failure, wasting valuable context tokens. Verbatim compaction is different. It selectively deletes messages that are no longer relevant,like the details of a test that's now passing,while preserving the full resolution of important messages, like a failing test's error output.
This is the secret sauce for multi-day runs. You can manually trigger it with `/compact`, or set it to auto-trigger at a certain context threshold. The system intelligently decides what to keep. Passing tests are pruned. Failing tests are kept verbatim. This ensures the model always has the critical information it needs without wasting space on noise.

Keep-Context Tags: Your Non-Negotiables

Even with verbatim compaction, there's a risk the agent will drift from your core requirements over a long session. That's where keep-context tags come in. You can enclose mission-critical instructions in these tags, and the runtime will deterministically preserve them across compaction cycles. It only removes them if the context window is irreversibly full.
For example, you might put `Make sure to write unit tests for every change.` at the start of a session. No matter how long the task runs or how many times the context is compacted, that instruction stays. This is your guarantee that the agent won't forget the non-negotiables. It's a powerful tool for enforcing standards on long-running, autonomous projects.

Intercom: Building a Team of Agents

Most agent designs are hierarchical: a main agent spawns a sub-agent, waits for it to finish, and then gets a dump of results. That's slow and inefficient. Intercom changes this by enabling dynamic, mid-stream communication between agents. You can have asynchronous sub-agents that send messages back to the main chat while they're still working. You can have peer-to-peer messaging between sessions, using their IDs as addresses.
This is how you build a real team of agents. You can have a worker agent implementing a feature, a reviewer agent analyzing the code, and a project manager agent coordinating the effort,all talking to each other in real-time. The power of this becomes even clearer with intercom groups. You can isolate agents into private communication channels. This is critical for verification workflows. If you have an adversarial reviewer, you don't want a worker agent to be able to message it and say, "Hey, I actually did this right, don't be too harsh." Scoped groups prevent that kind of contamination.

Intelligent Handoffs vs. Dumb Forks

When you want to hand off a task to another agent, you have a choice. The naive approach is to fork the entire context window and pass it along. That's a "dumb fork" because it carries a lot of irrelevant information. A better approach is to use intercom for an intelligent handoff. The model analyzes the conversation, determines what subset of information is relevant for the next agent, and sends a concise, targeted handoff message. This is more efficient and preserves the original session's context for its own tasks. It's a dynamic fork that only passes what matters.

The Workflow Engine: Processes as Code

This is the core of the Atomic runtime. Workflows are like sub-agents on steroids, but with deterministic, structured stages. Each stage has its own context window, clear handoffs, and verification gates. The engine is built on recursive state machines, which means workflows can be nested inside other workflows. This is how you build complex, multi-layered autonomous systems.
The runtime comes with several built-in patterns that cover a wide range of use cases. Let's break them down:

Classify and Act

This pattern is for when you have a task that could be solved in multiple ways. First, a classifier stage determines what type of task it is. Then, it routes the task to parallel implementation stages, each working in its own git worktree to avoid conflicts. Finally, a decision stage evaluates the results from each parallel stage and selects the best one. It's a great way to explore different implementation strategies without interfering with each other.

Fan-Out and Synthesize

This is the classic map-reduce pattern. You take a large task, split it into smaller pieces, and send each piece to a parallel worker stage. A barrier operation waits for all the workers to finish. Then, a synthesizer stage merges the results into a cohesive whole. This is perfect for tasks like "analyze this entire codebase for security vulnerabilities" where you can parallelize the analysis and then combine the findings.

Adversarial Verification

This pattern is all about quality control. A worker stage produces an output, which is then routed to multiple parallel verifiers. Each verifier checks for a different criterion. One might check code quality, another might check test coverage, and a third might check for performance regressions. A reducer stage then looks at all the verifier results and decides whether to loop back to the worker for fixes or to accept the output and move on. This is a powerful way to ensure high-quality output.

Generate and Filter

This is for creative or exploratory tasks. You have a generation stage that produces multiple candidate ideas or implementations. Then, a filter stage evaluates all the candidates and narrows them down to the most promising ones. You can even insert a human-in-the-loop gate here to let a person make the final selection. This is great for things like "generate three different UI designs for this dashboard and let me pick the best one."

Tournament

This pattern is like a bracket-style competition. Multiple attempts at a task are pitted against each other. Judge groups evaluate each match-up, and the winner advances to the next round. This continues until a single champion emerges. It's a more structured way to select the best implementation when you have many candidates, and it's particularly useful when the "best" is subjective and benefits from multiple rounds of comparison.

Looping Until Done

This is a simple but powerful pattern. It runs a task repeatedly until a clear completion criterion is met. The most common example is "run CI until green." The loop will run the tests, and if they fail, it will try to fix the code and run them again. It will keep doing this until the tests pass. Another example is "fix every review comment until none remain." It's a deterministic way to handle iterative tasks that have a clear endpoint.

The Goal Workflow and the Ralph Workflow

The Goal workflow is inspired by goal-based agents, but with a critical difference. Instead of the model self-assessing whether the goal is complete, it uses deterministic parallel reviewer judges. The task is only considered done when these external reviewers, along with test passes and artifact evidence, say it's done. The Ralph workflow is a more comprehensive research-and-implement loop. It starts with a prompt engineer stage that optimizes your request. Then a researcher gathers relevant codebase context. An orchestrator implements the change. Finally, two adversarial reviewers evaluate the work. If they fail it, the loop repeats. This is a full-fledged, high-assurance workflow for complex changes.

Invoking and Steering Workflows

You can trigger workflows deterministically with slash commands and structured input forms. Or, the main agent can spawn them contextually when it detects that high-assurance work is needed. Once a workflow is running, you can connect to it and watch the graph expand in real-time. You can see which stage is active, what tools are being called, and how long each stage has been running. You can pause, resume, or interrupt workflows at any point. This level of control is essential for managing long-running autonomous processes.

Building Custom Workflows with TypeScript

The built-in patterns are just the beginning. For advanced users, the TypeScript SDK allows you to author custom workflows from scratch. This is where you can encode your team's specific processes and best practices. You define custom schemas for typed inputs and outputs, ensuring strict data flow between stages. You can use deterministic tools like `git diff` or file reads as gates. You can create hooks that react to model events, like a safety classifier that evaluates every tool call.
This is the transition from natural language instructions to executable workflow code. It gives your team a new form of institutional memory. Instead of having your process rules buried in an `AGENTS.md` file that the model might ignore, you encode them in a workflow that the runtime enforces. The model can't skip a step because the workflow's structure doesn't allow it.

Human-in-the-Loop Gates

Not everything should be fully autonomous. Custom workflows can include human-in-the-loop gates. When the workflow reaches a certain point, it pauses and presents the user with a selection menu, an approval checkbox, or a free-text prompt. For example, you could create a "release decision" workflow that summarizes pending diffs, classifies the risk, and then waits for a human to approve before proceeding. This combines the efficiency of automation with the judgment of a human at critical decision points.

Model Orchestration: The Right Tool for the Job

You don't need to use the same model for every stage of a workflow. The runtime is model-agnostic. You can use a cheap, high-throughput model for worker stages that do the bulk of the implementation. Then, you can use a more powerful, frontier model for the reviewer stages that require complex reasoning. This is a cost-efficient strategy. In one documented example, a worker model cost about $0.12 per task, while more capable models were layered on top for review. This approach gives you high-quality results at a fraction of the cost of using a premium model for everything.
You can also integrate with various subscriptions and API keys, like Claude Code, Codex, GitHub Copilot, and others. This lets you leverage existing plans and subsidized usage. And if one model gets rate-limited or runs out of credits, the runtime can fail over to another provider, ensuring your workflow continues uninterrupted.

The Real-World Case Study: The Two-Day PR

Let's look at what this looks like in practice. A team was facing a critical bug where a service was consuming 1000% CPU. The engineer gave the agent runtime a simple instruction: fix it until it's done. Over the next two days, the agent autonomously split the work into a stack of 14 related pull requests. It spawned 98 workflows to manage different aspects of the task. It interacted with GitHub Actions and AI code reviewers. It discovered and fixed additional issues along the way. The engineer's primary role shifted to reviewing the agent-generated plans and occasionally steering it. This is the "manager" paradigm in action. The engineer defined the outcome, and the runtime handled the execution and verification.

From Vague Idea to Engineering Plan

Another powerful application is turning a vague product idea into a structured plan. A user asked the runtime to scope a notification system for a live-stream audience. In minutes, it generated a full specification. It recommended an authentication stack, a database choice, and a messaging provider. It compared international SMS and WhatsApp routing rules and provided cost projections. When comparing providers, it even pointed out hidden carrier fees and developer-experience tradeoffs, ultimately selecting a more mature SDK for future compatibility. This demonstrates how a runtime can act as a senior architect, turning a one-line request into a comprehensive engineering blueprint.

Migrating Skills to Workflows

Many teams have invested in skills files,step-by-step instructions for their agents. But these are model-dependent. A model might skip a step or diverge from the procedure. The solution is to convert your skills into deterministic workflows. The runtime can analyze a skill file, ask you targeted questions about scope and autonomy, and then produce a custom workflow that runs on every change without you having to remember to invoke it. This is a practical migration path. It takes your existing institutional knowledge and makes it enforceable.

The Pragmatic Evolution: Prompts, Skills, Workflows

The community has evolved from writing prompts to writing skill files to defining workflows. Each stage adds more determinism and reliability. Prompts are fine for one-off queries but unreliable for multi-step procedures. Skills improve consistency but still rely on model compliance. Workflows turn those instructions into a graph of stages with clear gates and guaranteed execution order. The key takeaway is that verification is more important than generation. The value of an agentic runtime is its ability to prove a task is complete, not just claim it.

Defining "Done" Before You Start

The most significant gains come from clear task specifications and explicit completion criteria. The runtime's own prompt-engineer skill can take a vague request and turn it into a structured task description. Its spec-creation skill asks adversarial questions to uncover weak assumptions. These built-in skills help you define what "done" means before starting long-running work. Don't think about just prompting locally; think about what the task is and how you, as an engineer, would approach solving that problem. The more specific you are, the better.

Key Insights for Your Practice

Here are the core principles to take with you. Workflows prevent skill drift because they are deterministic procedures that can't be skipped. Compaction matters, and verbatim compaction is essential for maintaining alignment across multi-hour runs. Parallel communication scales collaboration, and intercom groups let you design teams of agents that can work together or be isolated for independent review. Multi-model orchestration balances cost and quality. And above all, your role changes. You become a system designer, spec creator, and exception handler. The agents handle the execution and routine verification.

Actionable Recommendations

Start with a simple, well-scoped task. Write a precise specification and run a built-in workflow like Goal or Ralph to build familiarity. Use a multiplexer for long sessions so your agents can run on a server without interruption. Convert your existing skills to workflows. Define explicit completion criteria using a combination of automated tests and LLM-as-a-judge reviewers. Use keep-context tags for mission-critical objectives. Adopt cost-aware multi-model orchestration with fallbacks. Work in small, stacked diffs. Build a reviewer ecosystem with GitHub Actions and external AI reviewers. And invest time in spec-writing skills before starting any large project.

The New Engineering Discipline

The move toward verifiable agentic runtimes represents a fundamental shift in how software is engineered. By separating execution from verification, and by embedding engineering judgment into deterministic workflows, you can deploy AI agents that work continuously and accountably. The most successful engineers will not be those who write the most prompts, but those who design the most precise specifications and the most robust verification gates. In this emerging practice, the runtime is not just a tool. It's the new foundation of the engineering discipline itself. Your job is to define the process, set the gates, and let the system do the work. That's the future of engineering, and it's available now.

Frequently Asked Questions

This FAQ distills recurring questions about agentic engineering, the Atomic verifiable coding agent runtime, and how they show up in the Agentic Masterclass: In Practice with Alex (Atomic). The goal is simple: give you straight, practical answers so you can make clear decisions about where and how to use agentic systems in your work.
Use it as a reference: skim the basics if you're new, then move into workflows, verification, and real deployment patterns as your ambition (and risk profile) grows.

About the Agentic Masterclass & Atomic

What is the Agentic Masterclass: In Practice with Alex (Atomic)?

It's a practical training on how to think, build, and operate with verifiable coding agents using Atomic as the main example.
You're not just learning prompts; you're learning how to run AI as an engineering "team" that can work for hours or days with checks, balances, and evidence. The masterclass walks through concepts like sessions, workflows, verification gates, and inter-agent communication, then shows how they look in real projects: PR automation, greenfield builds, and ongoing maintenance.

Instead of theory-heavy lectures, you see how a runtime like Atomic changes your role from "person who writes all the code" to "person who defines clear outcomes, constraints, and verification." The focus is always: how does this reduce real bottlenecks,cycle time, review overhead, coordination,not just generate more code.

Who is this masterclass for?

It's for builders who are responsible for results, not just code.
That includes: product leaders, founders, tech leads, senior engineers, and ambitious generalists who want to coordinate AI work instead of poking at chatbots all day. If you own timelines, budgets, or quality, this is your territory.

You don't need to be a low-level systems engineer, but you should care about how software gets from idea to production. The material shows non-technical leaders how to specify outcomes and verification, and shows technical leaders how to encode those into workflows and runtimes. Think: "I want to ship real features, reduce manual review, and keep risk under control," rather than "I just want to play with a new model."

Do I need to be a strong programmer to benefit?

You need technical curiosity and basic literacy, not elite coding skills.
If you can read code, follow a pull request, and understand what tests do, you're in a good spot. The runtime handles most of the mechanical work; your job is to define intent, constraints, and what "good enough" looks like.

Strong programmers will see new ways to automate their own workflows and encode their judgment into repeatable systems. Less-technical operators will learn how to brief agents like senior contractors: outcome-focused, with clear success criteria and safety rails. Over time, the real skill you build is systems thinking,how to structure work so that agents can execute and verify it without you babysitting every line.

How is this different from a generic AI or "prompting" course?

Most courses teach you how to talk to a model; this one teaches you how to run it like an autonomous team with accountability.
Prompting alone hits a wall once tasks stretch beyond a single chat: specs drift, context overflows, and nobody can say with confidence whether something is truly done. Here, the focus is on runtimes, workflows, verification gates, and graph-like processes.

You learn how to combine models, tools, and deterministic checks so that multi-hour or multi-day work becomes reliable. That matters if you care about shipping to production, not just generating drafts. Think less "cool tricks in a chat UI" and more "how do we safely let an agent run overnight on our main repo without waking up to a mess?"

Fundamentals & Getting Started

What is Atomic and how does it differ from other coding agents like Claude Code or Codex?

Atomic is a verifiable coding agent runtime, not just a coding assistant.
Traditional tools live inside an editor or terminal: you prompt, they respond, you manually judge the output. Atomic sits underneath that as a runtime layer. It owns sessions, tools, models, workflows, and verification rules.

Key differences:
- Completion is decided by deterministic gates (tests, reviewers, artifacts), not the model saying "I'm done."
- Work is structured as workflows (graphs of stages) rather than one long chat.
- It's built for long-horizon tasks that can run for hours or days with checkpointing and compaction.
- It integrates inter-agent communication, so worker and reviewer agents can coordinate without you in the loop.

Think of Atomic as the operating system; models are just processes running inside it.

What is a "verifiable coding agent runtime" in simple terms?

It's an environment where an AI has to prove its work instead of asking you to trust it.
In a normal chat, the model writes code and tells you it's correct. In a verifiable runtime, completion is defined by evidence: passing tests, static checks, reviewer judgments, or structured artifacts. The runtime orchestrates these steps: run tests, collect logs, ask a separate judge model, gate progress on their answers.

For a business, this matters because you stop relying on vibes. You can say, "Ship only if this workflow says all verifiers passed," and treat that as a guardrail. The runtime becomes the contract: here's the process, here's what counts as done, here's the trail proving it.

What prerequisites do I need to install and run Atomic?

You need a basic development setup, an npm environment, and access to at least one model provider.
Atomic is installed as an npm package. On top of that, the recommended companion is Herder, a terminal multiplexer that lets long-running sessions continue even if you disconnect from a remote machine.

Practically, you'll want:
- A machine (local or cloud) with Node and git
- API keys or subscriptions for at least one LLM provider
- Comfort with a terminal and running commands

The official docs and crash course repo walk through installation, config, and first workflows step by step, so you don't have to reverse-engineer anything.

How do I begin using Atomic for basic coding tasks?

You can start by treating Atomic like an upgraded coding assistant in your terminal.
After installation, you run atomic and interact conversationally: ask for code, refactors, or debugging help. Useful basics include:
- Reference files with @file to inject them into context
- Run shell commands with !, then send their output into the chat with !!
- Let the agent read and edit files directly via its tools

This gets you comfortable with the interaction model. From there, you layer on sessions, workflows, and verification. The mental shift is: "I'm not just asking for snippets; I'm setting up tasks the agent can pursue across multiple steps with clear finish lines."

What careers skills does agentic engineering require?

The primary skill is systems judgment, not raw coding throughput.
You still benefit from knowing data structures, APIs, and debugging, but the leverage comes from:
- Defining clear specs and completion criteria
- Designing processes as workflows with checks and reviewers
- Deciding what should be automated and what stays human
- Controlling what reaches users and under which constraints

Think of it as moving up a level: instead of obsessing over every line, you architect the system that writes and verifies most of those lines for you. People who can combine technical depth with product sense and risk awareness are the ones who get the most out of agentic runtimes.

How does agentic engineering change the role of software teams and product orgs?

Teams shift from "doers of every step" to designers and governors of processes.
Engineers spend more time on specs, architecture, verification design, and incident handling. A lot of routine implementation, test scaffolding, and refactors can be pushed into workflows. Product managers and founders gain a more direct interface to execution by learning to define workflows and success conditions, not just tickets.

This doesn't remove humans; it reassigns them. Senior talent focuses on decisions, trade-offs, and constraints; agents handle the grind under those rules. Org-wise, you'll see fewer fire drills over massive diffs and more attention on verification quality, logging, and model selection.

Sessions, Context & Memory

What are Atomic's session primitives,treeing, forking, and cloning?

They're low-level tools for managing the agent's "memory" like an operating system manages processes.
- Treeing:
Jump back to an earlier message and continue from there, effectively erasing a bad path without losing the earlier conversation.
- Forking:
Copy the current context into a new session so you can explore an alternative approach in parallel.
- Cloning:
Create a new session with the same history but a fresh editor state.

In practice, this lets you correct mistakes, explore options, and reuse context without constantly re-prompting. It's especially valuable on long tasks where starting from scratch would waste time and tokens.

How do I practically use tree, fork, and clone during real projects?

Treat them like branches in git, but for conversations and context.
- Use treeing
when the agent has gone down a bad line of reasoning (wrong architecture, misread requirement). You jump back to the last "clean" checkpoint and redirect.
- Use forking
when you want two competing implementations or analyses. Example: "Fork this session and try a functional version instead of OOP."
- Use cloning
when you want the same background context but a totally different task,like starting a new feature that depends on the same prior research.

This keeps work structured and prevents one confused thread from polluting everything else.

How does Atomic handle context window limits for long-running tasks?

Atomic uses verbatim compaction instead of lossy summarization.
Most tools summarize old messages when the context is full. That sounds efficient but often deletes the exact details you need (like failing test output). Atomic instead selectively deletes low-value messages while preserving high-resolution information.

Typical rules:
- Keep failing tests verbatim so the agent can reason about them later
- Drop passing tests and stale chatter
- Respect "preserve recent" settings so the last N messages stay intact

You can trigger compaction manually with /compact or let autocompaction kick in based on configured ratios, keeping long sessions stable without constant manual trimming.

What are "keep context" tags and how do they improve task adherence?

They're explicit markers that tell Atomic, "Never drop this instruction unless there's absolutely no space left."
You wrap critical guidance inside special tags. During compaction, anything inside those tags is preserved deterministically. Example:

Example:
<keep-context>Every change must have unit tests and be under 150 lines per PR.</keep-context>

This prevents the classic failure where long sessions drift away from the original constraints. The agent itself can also detect important directions and wrap them in keep-context tags, creating a self-maintaining contract for multi-hour tasks.

What are common mistakes people make with context management?

The main mistake is treating context as infinite and hoping the model remembers everything.
Typical issues:
- Stuffing entire codebases into a single session instead of scoping work
- Repeating long instructions in every message instead of using keep-context tags
- Never compacting, so important details get pushed out of the window
- Mixing multiple projects into one session, which confuses the agent

Good practice looks like: one clear objective per session, frequent use of tree/fork, explicit keep-context for non-negotiables, and letting verbatim compaction clear the noise. That's how you keep long-running work sharp instead of chaotic.

Interaction Tools & Extensions

How does the "ask user question" tool work?

It forces the agent to clarify before acting, especially on ambiguous or high-cost tasks.
You can instruct: "Plan the config, don't write files yet, first ask me a question." The tool then pauses execution and presents interactive options or questions in your terminal,sometimes with simple diagrams or comparisons.

This is invaluable when a wrong assumption could waste hours of compute or create messy diffs. Instead of charging ahead, the agent checks: "Should we use provider A or B?" "Is performance or simplicity more important here?" That alignment up front saves you from cleaning up expensive mistakes later.

What are extensions and hooks in Atomic?

Extensions let you plug custom logic into the runtime; hooks control when that logic runs.
An extension might:
- Register custom tools (like /hello that runs a TypeScript function)
- Inspect or modify tool calls before they execute
- Attach behavior to model events (e.g., after every tool call, log a summary)

Hooks are the triggers. For example: "On any shell command, run this security check first." Or "After each workflow stage, push metrics to our dashboard." Because extensions can run arbitrary TypeScript, you can embed your domain rules, governance, and integrations directly into the runtime instead of duct-taping them around the edges.

How does Atomic handle dangerous command execution?

You can add a safety layer that inspects and blocks risky commands before they touch your system.
Common pattern:
- An extension hooks into shell tool calls
- It checks for patterns like rm -rf or production database access
- If flagged, it returns a block signal plus a reason and prompts you to approve or deny

More advanced setups run a small local model as a security auditor. Every command is sent through that auditor, which classifies it as safe, suspicious, or blocked. Because this auditing loop can run on your own hardware, it reduces exposure to prompt injection attacks that might try to manipulate cloud-hosted models.

How can I audit and govern what agents are allowed to touch in my codebase?

Treat the runtime like a policy engine: define what's allowed, then enforce it in extensions and workflows.
Practical moves:
- Restrict file access to specific directories per workflow (e.g., docs-only, tests-only)
- Add tools that whitelist or blacklist certain commands and paths
- Log every destructive action (deletes, migrations) with human-approvable gates
- Use workflows so risky operations always pass through reviewer stages

This lets you say things like, "Agents can refactor internal libs but cannot touch billing code without a human approval gate." The rules live in the runtime, not in tribal knowledge.

Intercom & Multi-Agent Collaboration

What is intercom and how does session-to-session communication work?

Intercom is a message bus that lets agents talk to each other mid-task, not just at the end.
Instead of one agent running a sub-agent and waiting for a big dump of results, intercom allows:
- Worker agents to send progress updates to orchestrators
- Reviewer agents to discuss and debate decisions
- Separate sessions to coordinate while staying context-isolated

You can address messages by session ID or use groups to target sets of agents. This opens up patterns like agent "panels," where multiple reviewers argue about correctness before a decision stage moves forward.

How does the "handoff" pattern work with intercom?

Handoff is about sending only the relevant slice of context to another agent, instead of copying everything.
With deterministic forking, you copy the full conversation into a new session. With intercom handoff, a model first prunes what's important,key decisions, error logs, diffs,and then sends a focused message to another session.

For example, a researcher session might summarize architecture choices and attach only the relevant files, then hand that to an implementer session. This is more context-efficient and makes each agent sharper, because they see the distilled signal, not hours of unfiltered conversation.

How can intercom help business teams, not just engineers?

Intercom lets you simulate multi-role teams of agents across business workflows.
Examples:
- A "researcher" agent gathers market intel, then hands off only the key points to a "strategy" agent that drafts options.
- A "customer voice" agent summarizes support tickets, then messages a "product planning" agent with patterns and edge cases.
- Finance, legal, and product agents can be grouped so they debate trade-offs before recommending a decision.

The pattern is the same as engineering: break roles apart, let them communicate through intercom, and then gate action on the combined output.

Workflows & Verification

What is a workflow in Atomic and how does it extend RLMs (Recursive Language Models)?

A workflow is a graph of agent stages with explicit rules about who runs when, with which inputs, and under which checks.
Each node is a session with its own context window; edges define handoffs and dependencies. Atomic calls this a recursive state machine: workflows can spawn sub-workflows, creating nested graphs.

This goes beyond simple recursive agent calls (RLMs) by making the structure inspectable, restartable, and verifiable. You can see which stage failed, why it failed, and what evidence it produced. Instead of "the model tried something," you get "this node ran, these tools executed, these tests passed, these reviewers signed off."

What built-in workflows ship with Atomic?

Atomic ships with eight proven patterns that cover most serious coding tasks.
Highlights:
- Classify and Act:
Route tasks to specialized paths and choose the best result.
- Fan Out and Synthesize:
Break work into parallel efforts, then merge.
- Adversarial Verification:
Worker + multiple verifiers + reducer.
- Generate and Filter:
Many ideas → filter → best few.
- Tournament:
Bracket-style competitions between implementations.
- Looping Until Done:
Iterate until tests and reviewers are satisfied.
- Goal Workflow:
Outcome-focused, with separate judge stages.
- Ralph Workflow:
Prompt engineering → research → implementation → adversarial review loop.

Each one encodes a strategy for getting reliable output from messy tasks.

When should I use a workflow versus working directly with the agent?

Use workflows when failure is expensive; use direct chat when experimentation is cheap.
Workflows shine when:
- Code touches production paths or user data
- Tasks span many steps or require multiple verifiers
- You want repeatability across people and projects

Direct interaction is fine for:
- Quick prototypes and "vibe coding"
- One-off scripts or refactors you can eyeball
- Exploration where learning matters more than polish

A useful rule: if you'd normally insist on tests, review, and a checklist for a human, encode that as a workflow. If you'd be okay with someone hacking a quick script and throwing it away, a simple session is enough.

What is an "assurance budget" and how does it guide workflow design?

Your assurance budget is how much time, compute, and human attention you're willing to spend to be confident something is right.
High-assurance work (payments, privacy, critical infra) deserves:
- Multiple reviewer agents
- Strict test gates
- Human approval steps
- Rich evidence artifacts (logs, screenshots, docs)

Low-assurance work (internal tooling, prototypes) might get a single agent with basic tests. Designing workflows is about matching the assurance budget to the risk. The mistake is spending "production-level certainty" on trivial tasks,or, worse, treating high-risk tasks like throwaway scripts.

How do loops and graphs relate to real business processes?

Loops model "fix and retry" cycles; graphs model handoffs between roles.
For example, a release process might look like:
- Implement → test → review → deploy
- If tests fail, loop back to implement
- If review fails, loop back with reviewer feedback

On a graph, each of these is a node. Edges define who hands what to whom. That's exactly how organizations already work; workflows just make it explicit and executable by agents. Once you see your processes as graphs and loops, you can ask: where should agents help, where must humans stay in, and what evidence do we need at each edge?

How do I create a custom workflow?

You can define workflows in plain language or in TypeScript, depending on your comfort level.
Two main paths:
- Natural language:
Describe the process ("Summarize all pending diffs, classify risk, and gate release on human approval"). Atomic asks clarifying questions, generates TypeScript, and registers the workflow.
- TypeScript SDK:
Define inputs, outputs, tasks, and tools programmatically with strict types.

The mindset: write down the process you'd hand to a senior engineer as a checklist, then convert that into a graph where each step is enforced by the runtime instead of "hopefully followed."

How do human-in-the-loop workflows work?

They pause at specific points, wait for your input, then continue automatically.
A workflow node can be marked as requiring human input. When execution reaches it, the workflow stops and shows you context plus an interface to respond,approve, reject, choose an option, or provide extra detail. Once you answer, the workflow resumes with that decision baked in.

Common uses:
- Release approvals
- Risk classifications
- Design or UX sign-off
- "Escalate to human" on ambiguous or high-impact changes

This lets you keep humans where judgment matters and let agents handle the grind between those checkpoints.

Can I monitor, pause, resume, and quit workflows?

Yes. You get real-time visibility and control over running graphs.
Using the workflow command, you can:
- Connect to a running workflow and see its graph, node states, and outputs
- Pause execution, which also pauses dependent nodes
- Resume from deterministic checkpoints, including the exact spot in a conversation
- Quit a workflow entirely if it's going in the wrong direction

Atomic checkpoints both the graph position and each node's context. That means you can pause in the middle of an edit, walk away, and later pick up without losing state or confusing the agent.

How does Atomic's workflow engine handle fault tolerance and self-correction?

It treats failures as data, not dead ends.
If a deterministic tool call fails (missing permission, bad config, broken command), the workflow can:
- Capture the error output as evidence
- Ask a separate "repair" stage to fix the underlying issue
- Retry the original tool call after repair

Because each stage has its own context and evidence, self-correction becomes a first-class pattern: "Something broke → diagnose → patch → prove it's fixed." This matters a lot for long-running tasks where manual babysitting isn't feasible.