Understanding how Aimogen executes AI tasks is key to using the plugin effectively, especially once you move beyond basic post generation. Aimogen is not a single “generate and return text” tool. It uses a structured execution flow that allows content creation, editing, chat, and automation to behave predictably, remain extensible, and scale across different use cases.
This document explains that execution flow from input to output, without going into developer-level internals.
The Core Idea #
Every AI action in Aimogen follows the same high-level pattern:
Input → Context → Provider → Execution → Post-Processing → Output
Whether you generate a post, edit content, respond in a chatbot, or run an OmniBlock workflow, the same logical stages are involved. The difference between features is how each stage is configured, not how the system works underneath.
1. Input: Where Execution Starts #
Execution begins when Aimogen receives input. Input can come from many sources:
- A post title entered manually
- A list of titles in bulk generators
- Content from an existing post
- Data from a CSV file
- RSS feed items
- YouTube captions
- Amazon product data
- Chat messages from users
- Form submissions
- Workflow outputs
At this stage, Aimogen does not call any AI. It simply collects and normalizes the input into a structured format.
2. Context: Adding Meaning to the Input #
Raw input is rarely enough to generate useful output. Aimogen enriches input with context before execution.
Context can include:
- System prompts and instructions
- User-defined prompts
- Post metadata (categories, tags, SEO data)
- Language and locale
- Embeddings (company knowledge, documents, products)
- Chat history (for chatbots)
- Workflow state (previous steps)
This is the stage where Aimogen decides what the AI should know before responding.
Context is built dynamically. Different features add different context layers, but the mechanism is the same.
3. Provider Selection #
Once context is prepared, Aimogen selects an AI provider.
The provider can be:
- The global default provider
- A provider assigned to the feature
- A provider chosen inside a workflow step
- A provider selected dynamically via rules
If multiple providers are available, Aimogen does not randomly switch between them unless instructed. Selection is deterministic and configurable.
If a provider is unavailable or fails, fallback logic may apply depending on your settings.
4. Model Resolution #
After the provider is chosen, Aimogen resolves the AI model.
This may be:
- A default model
- A feature-specific model
- A model explicitly selected in a workflow
- An assistant instead of a raw model
Model resolution also determines:
- Token limits
- Streaming behavior
- Vision or multimodal support
- Tool availability (functions, browsing, code execution)
This step ensures the request matches what the provider and model can actually handle.
5. Execution: The AI Call #
This is the point where Aimogen sends the request to the AI provider.
Execution includes:
- Sending input + context
- Applying temperature, penalties, verbosity, and reasoning settings
- Handling streaming or batch responses
- Respecting rate limits and quotas
Execution is logged in detail, including parameters and response metadata.
For long or complex tasks, execution may be:
- Batched
- Streamed
- Deferred to background processing
6. Post-Processing #
Once the AI response is received, Aimogen does not immediately output it.
Post-processing may include:
- Cleaning or formatting text
- Parsing structured responses
- Applying templates or shortcodes
- Inserting images or media
- SEO field population
- Duplicate checks
- Keyword replacement
- Validation or moderation
This stage turns raw AI output into something WordPress can use safely.
7. Output: Where Results Go #
The final output depends on the feature:
- A published or drafted post
- Updated post content
- Chatbot response
- Image or media attachment
- Workflow variable
- API response
- Log entry or statistic
Output is stored using standard WordPress mechanisms wherever possible, ensuring compatibility with themes and other plugins.
Execution Flow Variations #
While the flow stays the same, execution can behave differently depending on context.
Single-Step Execution #
Used for:
- Single post creation
- Manual content editing
- Simple chatbot responses
Multi-Step Execution #
Used for:
- OmniBlocks workflows
- Assistant-based tasks
- Content pipelines
Each step feeds its output into the next.
Persistent Execution #
Used for:
- Chatbots
- Assistants
- Embedding-based interactions
Context grows over time instead of resetting.
Why This Matters #
Understanding the execution flow helps you:
- Predict AI behavior
- Debug unexpected output
- Optimize costs
- Choose the right provider and model
- Build reliable workflows
- Extend Aimogen programmatically
It also explains why Aimogen can support so many features without becoming unstable: the execution engine is consistent, even when the use cases are not.
What This Means in Practice #
You don’t need to think about execution flow for basic usage. But once you start mixing providers, embeddings, workflows, chatbots, and automation, knowing how Aimogen thinks helps you get consistent, repeatable results.
Aimogen doesn’t guess. It executes a clearly defined flow every time — and that’s what makes advanced setups possible without sacrificing control.
