Add 19 example workflow packages demonstrating various patterns: Templates: - blank: Empty starter template - single_pass: Single AI request with tool execution - iterative_loop: AI loop until completion - contextual_iterative_loop: Loop with repository context - plan_execute_summarize: Planning and execution pattern Data Processing: - data_processing_demo: Filter, map, reduce operations - conditional_logic_demo: Branching logic - repo_scan_context: Repository scanning Plugin Test Suites: - dict/list/logic/math/string_plugins_test: Unit tests for plugins Infrastructure: - backend_bootstrap: Initialize backend services - default_app_workflow: Full application workflow - web_server_bootstrap/json_routes: Flask server setup Specialized: - game_tick_loop: Game loop pattern - testing_triangle: CI/CD test pipeline Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Default Application Workflow
The Default Application Workflow is AutoMetabuilder's production-ready system that combines backend initialization with an iterative AI agent loop. It demonstrates the framework's self-referential approach where internal logic is expressed as declarative workflows.
Overview
This workflow package replaces imperative Python code with a declarative JSON-based approach, providing a complete end-to-end workflow that bootstraps the backend and executes the AI loop.
Key Components
Phase 1: Backend Bootstrap (9 nodes)
Initializes all required services:
- Message loading from storage
- Metadata configuration
- Prompt template loading
- GitHub client initialization
- OpenAI client initialization
- Tool definitions loading
- Plugin loading and initialization
- Context seeding
- Message seeding
Phase 2: AI Agent Loop (8 nodes)
Executes the core agent through iterative cycles:
- Loading context
- Seeding messages
- Making LLM requests
- Executing tool calls
- Appending results
The loop continues for up to 10 iterations or until no tool calls are returned.
Main Advantages
The workflow-based architecture provides:
- Separation of Concerns: Clear boundaries between initialization and execution
- Flexibility: Easy to modify individual nodes without affecting others
- Observability: Each node execution can be logged and monitored
- Extensibility: New nodes can be added without changing existing ones
- Visual: The declarative format enables visual workflow editors
- Testable: Individual nodes can be unit tested in isolation
- Modular: Components can be reused across different workflows
File Structure
default_app_workflow/
├── package.json # Package metadata and configuration
├── workflow.json # Workflow definition with nodes and connections
└── README.md # This documentation file
Customization
To create a custom variant:
- Copy this package to a new directory
- Edit the
workflow.jsonfile to modify nodes or connections - Update the
package.jsonwith new name and description - Update any configuration references
Related Workflows
backend_bootstrap- Initialization onlysingle_pass- Single AI request without loopiterative_loop- Loop-only without bootstrapplan_execute_summarize- Advanced planning workflow
Architecture Notes
The system distinguishes between:
- Immutable Context: Configuration and dependencies that don't change during execution
- Mutable Store: Execution state that changes as the workflow progresses
This separation enables both workflow data flow and programmatic access patterns.
License
MIT