Blog

Meet the Workflows: Continuous Improvement

Jan 13, 2026

Don Syme

Peli de Halleux

Mara Kiefer

Welcome back to Peli’s Agent Factory!

In our previous posts, we’ve explored autonomous cleanup agents. Now we complete the picture with agents that analyze dependencies, type safety, and overall repository quality.

Continuous Improvement Workflows

Go Module Usage Expert (aka Go Fan) - Daily Go module usage reviewer
Typist - Analyzes type usage patterns for improved safety
Functional Pragmatist - Applies functional techniques pragmatically
Repository Quality Improver - Holistic code quality analysis

Go Module Usage Expert: The Dependency Enthusiast

The Go Module Usage Expert is perhaps the most uniquely characterized workflow in the factory - an “enthusiastic Go module expert” who performs daily deep-dive reviews of the project’s Go dependencies. This isn’t just dependency scanning - it’s thoughtful analysis of how well we’re using the tools we’ve chosen.

Most dependency tools focus on vulnerabilities or outdated versions. Go Module Usage Expert asks deeper and more positive questions: Are we using this module’s best features? Have recent updates introduced better patterns we should adopt? Could we use a more appropriate module for this use case? Are we following the module’s recommended practices?

Go Module Usage Expert uses an intelligent selection algorithm. It extracts direct dependencies from go.mod, fetches GitHub metadata for each dependency including last update time, sorts by recency to prioritize recently updated modules, uses round-robin selection to cycle through modules ensuring comprehensive coverage, and maintains persistent memory through cache-memory to track which modules were recently reviewed.

This ensures recently updated modules get reviewed first since new features might be relevant, all modules eventually get reviewed so nothing is forgotten, and reviews don’t repeat unnecessarily thanks to cache tracking.

For each module, Go Module Usage Expert researches the repository (releases, docs, best practices), analyzes actual usage patterns using Serena, and generates actionable recommendations. It saves summaries under scratchpad/mods/ and opens GitHub Discussions.

The output of Go Module Usage Expert is a discussion, which is then often “task mined” for actionable tasks using the TaskOps design pattern.

Let’s take a look at an example of how this works:

Go Module Usage Expert created the Go Module Review: actionlint discussion after noticing the actionlint module was updated.
Peli requested the Plan agent mine for actionable tasks.
This created a parent issue and 5 sub-tasks.
The subtasks were then solved by further workflow runs. An example PR is Implement parallel multi-file actionlint execution.

Through this multi-agent causal chain pattern, Go Module Usage Expert has generated 58 merged PRs out of 74 proposed (78% merge rate) across 67 module reviews. Notable chains include: spinner improvements (4 PRs from briandowns/spinner review), MCP SDK v1.2.0 upgrade (5 PRs from go-sdk review), and terminal styling overhaul (3 PRs from lipgloss review).

Typist: The Type Safety Advocate

The Typist analyzes Go type usage patterns with a singular focus: improving type safety. It hunts for untyped code that should be strongly typed, and identifies duplicated type definitions that create confusion.

Typist looks for untyped usages: interface{} or any where specific types would be better, untyped constants that should have explicit types, and type assertions that could be eliminated with better design. It also hunts for duplicated type definitions - the same types defined in multiple packages, similar types with different names, and type aliases that could be unified.

Using grep patterns and Serena’s semantic analysis, it discovers type definitions, identifies semantic duplicates, analyzes untyped usage patterns, and generates refactoring recommendations.

Typist also uses the TaskOps pattern. This means the job of Typist is not to fix code, but to analyze code and recommend possible improvements.

Let’s take a look at an example of this in practice:

Typist created the Typist - Go Type Consistency Analysis Report. This used grep and other tools to perform acomprehensive analysis examining 208 non-test Go files.
The report found 477 instances of map[string]any usage, 36 untyped constants and 30+ uses any in function signatures.
Peli requested /plan on that issue, causing the Plan agent to do further research and create 5 issues for work to be done such as Create unified ToolsConfig struct in tools_types.go.
4/5 of these issues were then solved by Copilot. For example Add unified ToolsConfig struct to replace map[string]any pattern.

Through this multi-agent causal chain, Typist has produced 19 merged PRs out of 25 proposed (76% merge rate) from 57 discussions → 22 issues → 25 PRs. The blog example (Discussion #4082 → Issue #4155 → PR #4158) is a verified causal chain.

The static v. dynamic typing debate has raged for decades. Today’s hybrid languages like Go, C#, TypeScript and F# support both strong and dynamic typing. Continuous typing improvement offers a new and refreshing perspective on this old debate: rather than enforcing strict typing upfront, we can develop quickly with flexibility, then let autonomous agents like Typist trail behind, strengthening type safety over time. This allows us to get the best of both worlds: rapid development without getting bogged down in type design, while still achieving strong typing and safety as the codebase matures.

Functional Pragmatist: The Pragmatic Purist

Functional Pragmatist applies moderate functional programming techniques to improve code clarity and safety, balancing pragmatism with functional principles.

The workflow focuses on seven patterns: immutability, functional initialization, transformative operations (map/filter/reduce), functional options pattern, avoiding shared mutable state, pure functions, and reusable logic wrappers.

It searches for opportunities (mutable variables, imperative loops, initialization anti-patterns, global state), scores by safety/clarity/testability improvements, uses Serena for deep analysis, and implements changes like converting to composite literals, using functional options, eliminating globals, extracting pure functions, and creating reusable wrappers (Retry, WithTiming, Memoize).

The workflow is pragmatic: Go’s simple style is respected, for-loops stay when clearer, and abstraction is added only where it genuinely improves code. It runs Tuesday and Thursday mornings, systematically improving patterns over time.

An example PR from our own use of this workflow is Apply functional programming and immutability improvements.

Functional Pragmatist (originally named “Functional Enhancer”) is a recent addition - so far it has created 2 PRs (both merged, 100% merge rate), demonstrating that its pragmatic approach to functional patterns is well-received.

Repository Quality Improver: The Holistic Analyst

Repository Quality Improver takes the widest view, selecting a different focus area each day to analyze the repository from that perspective.

It uses cache memory to ensure diverse coverage: 60% custom areas (repository-specific concerns), 30% standard categories (code quality, documentation, testing, security, performance), and 10% revisits for consistency.

Standard categories cover fundamentals. Custom areas are repository-specific: error message consistency, CLI flag naming conventions, workflow YAML generation patterns, console output formatting, configuration validation.

The workflow loads recent history, selects the next area, spends 20 minutes on deep analysis, generates discussions with recommendations, and saves state. It looks for cross-cutting concerns that don’t fit neatly into other categories but impact overall quality.

Example reports from our own use of this workflow are:

Through its multi-agent causal chain (59 discussions → 30 issues → 40 PRs), Repository Quality Improver has produced 25 merged PRs out of 40 proposed (62% merge rate), taking a holistic view of quality from multiple angles.

The Power of Continuous Improvement

These workflows complete the autonomous improvement picture: Go Module Usage Expert keeps dependencies fresh, Typist strengthens type safety, Functional Pragmatist applies functional techniques, and Repository Quality Improver maintains coherence.

Combined with earlier workflows, we have agents improving code at every level: line-level output (Terminal Stylist), function-level complexity (Code Simplifier), file-level organization (Semantic Function Refactor), pattern-level consistency (Go Pattern Detector), functional clarity (Functional Pragmatist), type safety (Typist), module dependencies (Go Module Usage Expert), and repository coherence (Repository Quality Improver).

This is the future of code quality: not periodic cleanup sprints, but continuous autonomous improvement across every dimension simultaneously.

Using These Workflows

You can add these workflows to your own repository and remix them. Get going with our Quick Start, then run one of the following:

Go Module Usage Expert:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/go-fan.md

Typist:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/typist.md

Functional Pragmatist:

gh aw add-wizard https://github.com/github/gh-aw/blob/main/.github/workflows/functional-programming-enhancer.md

Repository Quality Improver:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/repository-quality-improver.md

Then edit and remix the workflow specifications to meet your needs, regenerate the lock file using gh aw compile, and push to your repository. See our Quick Start for further installation and setup instructions.

You can also create your own workflows.

Next Up: Continuous Documentation

Beyond code quality, we need to keep documentation accurate and up-to-date as code evolves. How do we maintain docs that stay current?

Continue reading: Continuous Documentation Workflows →

Learn More

GitHub Agentic Workflows - The technology behind the workflows
Quick Start - How to write and compile workflows

This is part 5 of a 19-part series exploring the workflows in Peli’s Agent Factory.

Meet the Workflows: Continuous Style

Jan 13, 2026

Don Syme

Peli de Halleux

Mara Kiefer

Welcome back to Peli’s Agent Factory!

In our previous posts, we’ve explored how autonomous cleanup agents work continuously in the background, simplifying code and improving structure. Today’s post is dedicated to one agent, and the larger admirable concept it represents: continuously making things beautiful.

A Continuous Style Workflow

Today’s post is dedicated to one agent, and the larger concept it represents: the Terminal Stylist workflow. This agent’s purpose is to make things look better, by reviewing and enhancing the style of command-line interface (CLI) output.

Command-line interfaces are a primary interaction point for developer tools. When output is inconsistent or noisy, it still “works,” but it adds friction. When it’s well-styled, information becomes scannable, color highlights what matters, layouts remain readable across light and dark themes, and the overall experience feels professional.

Under the hood, the workflow looks for non-test Go files with console-related code and patterns such as fmt.Print*, console.*, and Lipgloss usage. It then checks for consistency in formatting helpers (especially for errors), sensible TTY-aware rendering, and accessible color choices. When it finds rough edges, it proposes concrete improvements, such as replacing plain output like fmt.Println("Error: compilation failed") with fmt.Fprintln(os.Stderr, console.FormatErrorMessage("Compilation failed")), or swapping ad-hoc ANSI coloring for adaptive Lipgloss styles.

Rather than opening issues or PRs, the Terminal Stylist posts GitHub Discussions in the “General” category. Styling changes are often subjective, and discussions make it easier to converge on the right balance between simplicity and polish.

Terminal Stylist demonstrates multi-agent collaboration at its best. The workflow created 31 daily analysis reports as discussions, which were then mined by Discussion Task Miner and Plan Command into 25 actionable issues. Those issues spawned 16 merged PRs (80% merge rate) improving console output across the codebase - from Charmbracelet best practices adoption to progress bars to stderr routing fixes. Terminal Stylist never creates PRs directly; instead, it identifies opportunities that other agents implement, showing how workflows can collaborate through GitHub’s discussion → issue → PR pipeline.

The Terminal Stylist is proof that autonomous cleanup agents can have surprisingly specific taste. It focuses on terminal UI craft, using the Charmbracelet ecosystem (especially Lipgloss and Huh) to keep the CLI not just correct, but pleasant to use.

The Art of Continuous Style

The Terminal Stylist shows that autonomous improvement isn’t limited to structure and correctness; it also covers user experience. By continuously reviewing output patterns, it helps new features match the project’s visual language, keeps styling aligned with evolving libraries, and nudges the CLI toward accessibility and clarity.

This is especially useful in AI-assisted development, where quick suggestions tend to default to fmt.Println. The Terminal Stylist cleans up after the AI, bringing that output back in line with the project’s conventions.

Continuous Style is a new frontier in code quality. It recognizes that how code looks matters just as much as how it works. By automating style reviews, we ensure that every interaction with our tools feels polished and professional.

Using These Workflows

You can add this workflow to your own repository and remix it as follows:

Terminal Stylist:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/terminal-stylist.md

Then edit and remix the workflow specification to meet your needs, regenerate the lock file using gh aw compile, and push to your repository. See our Quick Start for further installation and setup instructions.

You can also create your own workflows.

Next Up: Continuous Improvement

Beyond simplicity, structure, and style, there’s a final dimension: holistic quality improvement. How do we analyze dependencies, type safety, and overall repository health?

Continue reading: Continuous Improvement Workflows →

Learn More

Learn more about GitHub Agentic Workflows, try the Quick Start guide, and explore Charmbracelet, the terminal UI ecosystem referenced by the Terminal Stylist.

This is part 4 of a 19-part series exploring the workflows in Peli’s Agent Factory.

Meet the Workflows: Continuous Refactoring

Jan 13, 2026

Don Syme

Peli de Halleux

Mara Kiefer

Welcome back to Peli’s Agent Factory!

In our previous post, we met automated agents that detect complexity and propose simpler solutions. These work tirelessly in the background, cleaning things up. Now let’s explore similar agents that take a deeper structural view, extending the automation to structural refactoring.

Continuous Refactoring

Our next two agents continuously analyze code structure, suggesting systematic improvements:

Semantic Function Refactor - Spots refactoring opportunities we might have missed
Large File Simplifier - Monitors file sizes and proposes splitting oversized files

The Semantic Function Refactor workflow combines agentic AI with code analysis tools to analyze and address the structure of the entire codebase. It analyzes all Go source files in the pkg/ directory to identify functions that might be in the wrong place.

As codebases evolve, functions sometimes end up in files where they don’t quite belong. Humans struggle to notice these organizational issues because we work on one file at a time and focus on making code work rather than on where it lives.

The workflow performs comprehensive discovery by

algorithmically collecting all function names from non-test Go files, then
agentically grouping functions semantically by name and purpose.

It then identifies functions that don’t fit their current file’s theme as outliers, uses Serena-powered semantic code analysis to detect potential duplicates, and creates issues recommending consolidated refactoring. These issues can then be reviewed and addressed by coding agents.

The workflow follows a “one file per feature” principle: files should be named after their primary purpose, and functions within each file should align with that purpose. It closes existing open issues with the [refactor] prefix before creating new ones. This prevents issue accumulation and ensures recommendations stay current.

In our extended use of Semantic Function Refactoring, the workflow has driven 112 merged PRs out of 142 proposed (79% merge rate) through causal chains - creating 99 refactoring issues that downstream agents turn into code changes. For example, issue #12291 analyzing code organization opportunities led to PR #12363 splitting permissions.go into focused modules (928→133 lines).

An example PR from our own use of this workflow is Move misplaced extraction functions to frontmatter_extraction.go.

Large File Simplifier: The Size Monitor

Large files are a common code smell - they often indicate unclear boundaries, mixed responsibilities, or accumulated complexity. The Large File Simplifier workflow monitors file sizes daily and creates actionable issues when files grow too large.

The workflow runs on weekdays, analyzing all Go source files in the pkg/ directory. It identifies the largest file, checks if it exceeds healthy size thresholds, and creates a detailed issue proposing how to split it into smaller, more focused files.

What makes this workflow effective is its focus and prioritization. Instead of overwhelming developers with issues about every large file, it creates at most one issue, targeting the largest offender. The workflow also skips if an open [file-diet] issue already exists, preventing duplicate work.

In our extended use, Large File Simplifier (also known as “Daily File Diet”) has driven 26 merged PRs out of 33 proposed (79% merge rate) through causal chains - creating 37 file-diet issues targeting the largest files, which downstream agents turn into modular code changes. For example, issue #12535 targeting add_interactive.go led to PR #12545 refactoring it into 6 domain-focused modules.

The workflow uses Serena for semantic code analysis to understand function relationships and propose logical boundaries for splitting. It both counts lines and analyzes the code structure to suggest meaningful module boundaries that make sense.

The Power of Continuous Refactoring

These workflows demonstrate how AI agents can continuously maintain institutional knowledge about code organization. The benefits compound over time: better organization makes code easier to find, consistent patterns reduce cognitive load, reduced duplication improves maintainability, and clean structure attracts further cleanliness. They’re particularly valuable in AI-assisted development, where code gets written quickly and organizational concerns can take a backseat to functionality.

Using These Workflows

You can add these workflows to your own repository and remix them. Get going with our Quick Start, then run one of the following:

Semantic Function Refactor:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/semantic-function-refactor.md

Large File Simplifier:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/daily-file-diet.md

You can also create your own workflows.

Next Up: Continuous Style

Beyond structure and organization, there’s another dimension of code quality: presentation and style. How do we maintain beautiful, consistent console output and formatting?

Continue reading: Meet the Workflows: Continuous Style →

Learn More

GitHub Agentic Workflows - The technology behind the workflows
Quick Start - How to write and compile workflows

This is part 3 of a 19-part series exploring the workflows in Peli’s Agent Factory.

Meet the Workflows: Continuous Simplicity

Jan 13, 2026

Don Syme

Peli de Halleux

Mara Kiefer

Ah, what marvelous timing! Come, come, let me show you the next wonders in Peli’s Agent Factory!

In our previous post, we explored how a simple triage workflow helps us stay on top of incoming activity - automatically labeling issues and reducing cognitive load.

Now let’s meet the agents that work quietly in the background to keep code simple and clean. These workflows embody a powerful principle: code quality is not a destination, it’s a continuous practice. While developers race ahead implementing features and fixing bugs, autonomous cleanup agents trail behind, constantly sweeping, polishing, and simplifying. Let’s meet the agents that hunt for complexity.

Continuous Simplicity

The next two agents represent different aspects of code simplicity: detecting overcomplicated code and duplicated logic:

Automatic Code Simplifier - Analyzes recently modified code and creates PRs with simplifications
Duplicate Code Detector - Uses Serena’s semantic analysis to identify duplicate code patterns

The Automatic Code Simplifier runs daily, analyzing recently modified code for opportunities to simplify without changing functionality. It looks at what changed in the last few commits and asks: “Could this be clearer? Could it be shorter? Could it be more idiomatic?”

This workflow is particularly valuable after rapid development sessions. When you’re racing to implement a feature or fix a bug, code often becomes more complex than necessary. Variables get temporary names, logic becomes nested, error handling gets verbose. The workflow tirelessly cleans up after these development sessions, creating PRs that preserve functionality while improving clarity, consistency, and maintainability.

The kinds of simplifications it proposes range from extracting repeated logic into helper functions to converting nested if-statements to early returns. It spots opportunities to simplify boolean expressions, use standard library functions instead of custom implementations, and consolidate similar error handling patterns.

Code Simplifier is a recent addition - so far it has created 6 PRs (5 merged, 83% merge rate), such as extracting an action mode helper to reduce code duplication and simplifying validation config code for clarity.

The Duplicate Code Detector uses traditional, road-tested semantic code analysis in conjunction with agentic reasoning to find duplicate patterns. It understands code meaning rather than just textual similarity, catching patterns where:

The same logic appears with different variable names
Similar functions exist across different files
Repeated patterns could be extracted into utilities
Structure is duplicated even if implementation differs

What makes this workflow special is its use of semantic analysis through Serena - a powerful coding agent toolkit capable of turning an LLM into a fully-featured agent that works directly on your codebase. When we use Serena, we understand code at the compiler-resolved level, not just syntax.

The workflow focuses on recent changes in the latest commits, intelligently filtering out test files, workflows, and non-code files. It creates issues only for significant duplication: patterns spanning more than 10 lines or appearing in 3 or more locations. It performs a multi-phase analysis. It starts by setting up Serena’s semantic environment for the repository, then finds changed .go and .cjs files while excluding tests and workflows. Using get_symbols_overview and find_symbol, it understands structure, identifies similar function signatures and logic blocks, and compares symbol overviews across files for deeper similarities. It creates issues with the [duplicate-code] prefix and limits itself to 3 issues per run, preventing overwhelm. Issues include specific file references, code snippets, and refactoring suggestions.

In our extended use of Duplicate Code Detector, the agent has raised 76 merged PRs out of 96 proposed (79% merge rate), demonstrating sustained practical value of semantic code analysis. Recent examples include refactoring expired-entity cleanup scripts to share expiration processing and refactoring safe-output update handlers to eliminate duplicate control flow.

Continuous AI for Simplicity - A New Paradigm

Together, these workflows point towards an emerging shift in how we maintain code quality. Instead of periodic “cleanup sprints” or waiting for code reviews to catch complexity, we have agents that clean up after us and continuously monitor and propose improvements. This is especially valuable in AI-assisted development. When developers use AI to write code faster, these cleanup agents ensure speed doesn’t sacrifice simplicity. They understand the same patterns that humans recognize but apply them consistently across the entire codebase, every day.

The workflows never take a day off, never get tired, and never let technical debt accumulate. They embody the principle that good enough can always become better, and that incremental improvements compound over time.

Using These Workflows

You can add these workflows to your own repository and remix them. Get going with our Quick Start, then run one of the following:

Automatic Code Simplifier:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/code-simplifier.md

Duplicate Code Detector:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/duplicate-code-detector.md

You can also create your own workflows.

Next Up: Continuous Refactoring

Simplification is just the beginning. Beyond removing complexity, we can use agents to continuously improve code in many more ways. Our next posts explore this topic.

Continue reading: Continuous Refactoring →

Learn More

GitHub Agentic Workflows - The technology behind the workflows
Quick Start - How to write and compile workflows

This is part 2 of a 19-part series exploring the workflows in Peli’s Agent Factory.

Meet the Workflows: Issue Triage

Jan 13, 2026

Don Syme

Peli de Halleux

Mara Kiefer

Welcome back to Peli’s Agent Factory!

We’re the GitHub Next team. Over the past months, we’ve built and operated a collection of automated agentic workflows. These aren’t just demos - these are real agents doing actual work in our github/gh-aw repository and others.

Think of this as your guided tour through our agent factory. We’re showcasing the workflows that caught our attention. Every workflow links to its source markdown file, so you can peek under the hood and see exactly how it works.

Starting Simple: Automated Issue Triage

To start the tour, let’s begin with one of the simpler workflows that handles incoming activity - issue triage.

Issue triage represents a “hello world” of automated agentic workflows: practical, immediately useful, relatively simple, and impactful. It’s used as the starter example in other agentic automation technologies like Claude Code in GitHub Actions.

When a new issue is opened, the triage agent analyzes its content, does research in the codebase and other issues, responds with a comment, and applies appropriate labels based on predefined categories. This helps maintainers quickly understand the nature of incoming issues without manual review.

Let’s take a look at the full Issue Triage Agent:

---
timeout-minutes: 5

on:
  issue:
    types: [opened, reopened]

permissions:
  issues: read

tools:
  github:
    toolsets: [issues, labels]

safe-outputs:
  add-labels:
    allowed: [bug, feature, enhancement, documentation, question, help-wanted, good-first-issue]
  add-comment: {}
---

# Issue Triage Agent

List open issues in ${{ github.repository }} that have no labels. For each
unlabeled issue, analyze the title and body, then add one of the allowed
labels: `bug`, `feature`, `enhancement`, `documentation`, `question`,
`help-wanted`, or `good-first-issue`.

Skip issues that:
- Already have any of these labels
- Have been assigned to any user (especially non-bot users)

Do research on the issue in the context of the codebase and, after
adding the label to an issue, mention the issue author in a comment, explain
why the label was added and give a brief summary of how the issue may be
addressed.

Note how concise this is - it’s like reading a to-do list for the agent. The workflow runs whenever a new issue is opened or reopened. It checks for unlabeled issues, analyzes their content, and applies appropriate labels based on content analysis. It even leaves a friendly comment explaining the label choice.

In the frontmatter, we define permissions, tools, and safe outputs. This ensures the agent only has access to what it needs and can’t perform any unsafe actions. The natural language instructions in the body guide the agent’s behavior in a clear, human-readable way.

Issue triage workflows in public repositories may need to process issues from all contributors. By default, min-integrity: approved restricts agent visibility to owners, members, and collaborators. If you are a maintainer in a public repository and need your triage agent to see and label issues from users without push access, set min-integrity: none in your GitHub tools configuration. See Integrity Filtering for security considerations and best practices.

We’ve deliberately kept this workflow ultra-simple. In practice, in your own repo, customization is key. Triage differs in every repository. Tailoring workflows to your specific context will make them more effective. Generic agents are okay, but customized ones are often a better fit.

Using These Workflows

You can add this workflow to your own repository and remix it as follows:

Issue Triage Agent:

gh aw add-wizard https://github.com/github/gh-aw/blob/v0.45.5/.github/workflows/issue-triage-agent.md

You can also create your own workflows.

Next Up: Code Quality & Refactoring Workflows

Now that we’ve explored how triage workflows help us stay on top of incoming activity, let’s turn to something far more radical and powerful: agents that continuously improve code.

Continue reading: Continuous Simplicity →

Learn More

GitHub Agentic Workflows - The technology behind the workflows
Quick Start - How to write and compile workflows

This is part 1 of a 19-part series exploring the workflows in Peli’s Agent Factory.