Autensa (mission-control)

Once features are shipped, the system utilizes specialized agents to manage ongoing product operations:

• SEO Agent: Performs weekly SEO audits, generates meta/Open Graph tags, identifies keyword opportunities, and integrates with Google Search Console to feed insights back into the research agent.
• Content Agent: Manages the content lifecycle (outline → draft → review → publish) for blog posts, documentation, and landing pages. It uses research-driven opportunities to populate the swipe deck with content category ideas.
• Social Media Agent: Manages a dedicated review queue for social posts (Twitter/X, LinkedIn). It generates announcements for new features or content and tracks engagement. Note: Posts are never auto-posted without user approval.
• Analytics Agent: Monitors product health by tracking feature usage, error rates, and conversion funnels. It delivers weekly automated reports and immediate anomaly alerts (e.g., traffic or error spikes).
• Keyword & Growth Agent: Executes growth loops by identifying long-tail keyword opportunities and feeding growth category ideas into the swipe deck for the Content and SEO agents to execute.

Convoy Mode is an opt-in feature in Mission Control that enables parallel execution of sub-tasks. Instead of a single agent handling a complex task sequentially, a parent task can be decomposed into multiple sub-tasks that are assigned to different agents simultaneously.

Key Capabilities:

• Task Decomposition: A parent task is broken into sub-tasks via AI or manual intervention.
• Parallel Execution: Multiple agents work on different sub-tasks within the same convoy.
• Checkpointing: Agents save work state to the database to allow for crash recovery without starting from scratch.
• Health Monitoring: Real-time tracking of agent states (e.g., stalled, stuck, zombie) with automatic escalation.
• Inter-Agent Communication: Agents within a convoy can communicate directly using mailboxes.

Lifecycle Model:

1. Planning: Spec generation occurs.
2. Decomposition: The task is split into sub-tasks.
3. Convoy Creation: The parent task becomes a convoy and enters the convoy_active status.
4. Parallel Execution: Sub-tasks run through their own lifecycles (in_progress → testing).
5. Integration: Once all sub-tasks complete, the convoy moves to review for human approval.

User creates task
       ↓
   PLANNING (spec generation)
       ↓
   DECOMPOSITION ← NEW: AI or human breaks task into sub-tasks
       ↓
  CONVOY CREATED (parent task becomes convoy)
       ↓
  ┌──────────────────────────────────────┐
  │  Sub-task A → Agent 1 → Testing → ✓ │
  │  Sub-task B → Agent 2 → Testing → ✓ │  ← Parallel execution
  │  Sub-task C → Agent 3 → Testing → ✓ │
  └──────────────────────────────────────┘
       ↓
  CONVOY COMPLETE (all sub-tasks done)
       ↓
  INTEGRATION (optional: merge/verify combined output)
       ↓
    REVIEW (human reviews full convoy output)
       ↓
     DONE

A convoy moves through a state machine to manage parallel execution:

1. Creation: A task is converted into a convoy via POST /api/tasks/{id}/convoy using either manual or ai strategy.
2. Decomposition: If strategy = 'ai', the system decomposes the parent task into sub-tasks with titles, descriptions, and optional agent assignments.
3. Dispatch: POST /api/tasks/{id}/convoy/dispatch identifies sub-tasks in inbox status that are not blocked by their depends_on requirements and dispatches them.
4. Execution: Sub-tasks progress through assigned → in_progress → testing → done.
5. Completion: Once completed_subtasks == total_subtasks, the convoy moves to completing (for integration/verification) and then to DONE or review for human approval.
6. Failure: If a sub-task fails testing beyond the retry limit, it is marked failed. If the number of failed sub-tasks exceeds the convoy's failure threshold (default: total/2), the entire convoy moves to FAILED.

Agents are monitored via a health check cycle. The following states are used to determine if an agent needs intervention:

Escalation Actions

• stalled: Logs a warning to task activity.
• stuck: Increments consecutive_stall_checks. After 3 checks, an automatic nudge is triggered.
• zombie: Marks the session as dead and re-dispatches the task using the latest checkpoint.

The Product Program is a markdown document (analogous to Karpathy's program.md) that instructs research and ideation agents. It defines the identity, purpose, and constraints of your product.

Key sections include:

• Identity: Name, type, repo, live URL, and tech stack.
• Purpose: What the product does and who it is for.
• Target Users: User profiles and their problems.
• Business Model: Revenue drivers.
• Competitive Landscape: Competitors and differentiators.
• Priorities: Ranked or weighted goals (e.g., growth, stability, UX).
• Constraints: Technical, budget, or timeline limitations.
• Research Directives: Specific areas for the research agent to focus on (e.g., "Look for ways to reduce churn").
• Exclusions: Explicitly forbidden suggestions (e.g., "No blockchain features").
• Learned Preferences: An auto-populated section updated by the learning engine based on your swipe history.

# Product Program: [Product Name]

## Identity
- Name: Autensa (Mission Control)
- Type: Web application (Next.js + SQLite)
- Repo: https://github.com/crshdn/mission-control
- Live URL: http://192.168.1.65:4000
- Stack: Next.js 14, React 18, SQLite (better-sqlite3), TypeScript, Tailwind CSS

## Purpose
What this product does and who it's for. Written by the user or generated by AI.

## Target Users
Who uses this and what problems they have.

## Business Model
How this makes money (if applicable). What drives revenue.

## Competitive Landscape
Known competitors, differentiators, market position.

## Priorities
What matters most — growth, stability, features, UX, performance, etc.
User can rank or weight these.

## Constraints
Technical limitations, budget constraints, timeline pressure, etc.

## Research Directives
Specific areas the user wants the research agent to focus on.
Example: "Focus on features that enterprise customers need" or
"Look for ways to reduce churn" or "Find integration opportunities."

## Exclusions
Things the user explicitly does NOT want suggested.
Example: "No blockchain features" or "Don't suggest mobile app — we're web only."

## Learned Preferences
[Auto-populated from swipe history]
This section is updated automatically as the learning engine accumulates data.

The Agent Skill Creation Loop is a closed-loop system designed to transform transient agent experiences into reusable, executable playbooks called product_skills. Unlike the generic knowledge_entries which store text blobs about what happened, product_skills are structured, actionable procedures scoped to specific products.

The loop consists of four phases:

1. Capture (post-task): When a task completes (success or instructive failure), the system prompts the agent to extract reusable procedures and POST them to the skills API.
2. Match (pre-dispatch): Before an agent is dispatched, the system queries product_skills for the product and matches them based on skill_type, trigger_pattern (regex), or confidence scores. These are injected as primary instructions in the dispatch message.
3. Report (during task): Agents call a reporting endpoint to indicate if a skill was used, if it succeeded, and if any deviations occurred.
4. Improve (periodic): A background process promotes draft skills to active, deprecates low-confidence skills, and handles versioning via supersedes_skill_id.