Continuous Optimisation Lifecycle

Every domain controller drives a continuous, autonomous feedback loop — observation, recommendation, execution, and measurement — compounding intelligence across every interaction. This is how Weblisk systems get smarter over time without manual tuning.

The Cycle

┌────────────────────────────────────────────┐
│                                            │
▼                                            │
┌─────────────────┐                          │
│  1. STRATEGISE   │  Define objectives       │
└────────┬────────┘                          │
         │                                   │
         ▼                                   │
┌─────────────────┐                          │
│  2. OBSERVE      │  Agents collect data     │
└────────┬────────┘                          │
         │                                   │
         ▼                                   │
┌─────────────────┐                          │
│  3. RECOMMEND    │  Agents propose changes  │
└────────┬────────┘                          │
         │                                   │
         ▼                                   │
┌─────────────────┐                          │
│  4. EXECUTE      │  Apply approved changes  │
└────────┬────────┘                          │
         │                                   │
         ▼                                   │
┌─────────────────┐                          │
│  5. MEASURE      │  Compare before / after  │
└────────┬────────┘                          │
         │                                   │
         ▼                                   │
┌─────────────────┐                          │
│  6. LEARN        │  Update metrics, refine  │
└────────┴────────────────────────────────────┘

The loop runs continuously. Each completed cycle feeds into the next: observations from the latest execution inform the next round of recommendations, and feedback from measurements refines future strategy.

Phase 1 — Strategise

A strategy is a business objective with measurable targets and a deadline. Strategies are created by users or external systems and stored by the orchestrator via POST /v1/strategy.

{
  "id": "strat-001",
  "name": "Improve organic traffic",
  "objective": "Increase organic search traffic by 40% in Q3",
  "targets": [
    {
      "metric": "organic_sessions",
      "current": 12000,
      "goal": 16800,
      "deadline": "2026-09-30",
      "unit": "sessions/month",
      "progress": 0.0
    }
  ],
  "priority": 1,
  "status": "active"
}

Strategy Decomposition

The orchestrator maps strategies to domains. A strategy targeting SEO metrics routes to the SEO domain. The domain interprets the strategy's targets and selects appropriate workflows.

Multiple strategies can be active simultaneously. Domains prioritise tasks from higher-priority strategies.

Phase 2 — Observe

Agents collect structured measurements about the current state. Observations are the raw data that the system reasons about.

Who: work agents, dispatched by domains during workflow execution.
Produces: Observation with Finding entries.

{
  "id": "obs-001",
  "agent_name": "seo-analyzer",
  "target": "app/index.html",
  "timestamp": "2026-04-16T10:00:00Z",
  "measurements": {
    "title_length": 4,
    "meta_description_length": 0,
    "h1_count": 0,
    "image_count": 5,
    "images_missing_alt": 3
  },
  "findings": [
    {
      "rule_id": "seo-title-length",
      "severity": "critical",
      "element": "title",
      "current": "Home",
      "expected": "30-60 characters",
      "message": "Title too short for SEO",
      "fixable": true,
      "fix": "Weblisk — Modern Web Framework"
    }
  ],
  "strategy_id": "strat-001"
}

Observations are immutable once recorded. They represent a point-in-time measurement. Comparing observations over time reveals trends.

Data Flow

1. Domain dispatches task → agent scans target
2. Agent records measurements and identifies findings (rule violations)
3. Agent returns Observation to domain
4. Domain forwards to orchestrator
5. Orchestrator stores in observation history (GET /v1/observations)

Phase 3 — Recommend

Based on observations, agents propose concrete changes with estimated impact and priority.

Who: work agents (as part of workflow), aggregated by domains.
Produces: Recommendation entries.

{
  "id": "rec-001",
  "observation_id": "obs-001",
  "agent_name": "seo-analyzer",
  "strategy_id": "strat-001",
  "target": "app/index.html",
  "action": "modify",
  "element": "title",
  "current": "Home",
  "proposed": "Weblisk — Modern Web Framework",
  "reason": "Title under 10 chars — search engines truncate or ignore short titles",
  "priority": "critical",
  "impact": 0.8,
  "status": "pending"
}

Priority Levels

Impact Score

A 0.0 to 1.0 estimate of how much this change affects the strategy's target metric. Work agents estimate this based on domain knowledge; the system refines estimates over time using feedback data.

Approval Workflow

1. Recommendation created (status: "pending")
2. If domain.approval = "auto" AND priority ≠ "critical":
   status → "accepted" (auto-approved)
3. If domain.approval = "required" OR priority = "critical":
   status stays "pending" until human review
4. Human approves → "accepted"
5. Human rejects → "rejected" (with reason)

Phase 4 — Execute

Accepted recommendations are applied. The domain controller creates ProposedChange entries.

Who: domain controller, with work agents for complex changes.
Produces: ProposedChange entries in TaskResult.

1. Resolve the target (file path, URL, resource)
2. Apply the change:
   • File modification: read original → apply change → write modified
   • Configuration change: update config value
   • External action: API call, deployment trigger
3. Record the change: path, action, original, modified, diffs
4. Set recommendation status → "applied"

All changes are recorded with full before/after content so they can be reviewed, diffed, and reverted.

Phase 5 — Measure

After changes are applied, the system measures their effect. This closes the observation loop.

Who: same work agents that produced the original observations.
Produces: Feedback entries.

1. Wait for measurement window (configured per strategy — e.g. 24 hours for SEO, minutes for performance)
2. Re-run the same observation workflow
3. Compare new measurements to pre-change observations
4. For each applied recommendation: find the original and new observation, compare the relevant metric, create Feedback entry

{
  "id": "fb-001",
  "recommendation_id": "rec-001",
  "type": "metric",
  "signal": "positive",
  "detail": "Title length improved from 4 to 42 characters",
  "metric_before": 4,
  "metric_after": 42,
  "metric_name": "title_length",
  "timestamp": "2026-04-17T10:00:00Z"
}

Signal Types

Feedback Sources

Phase 6 — Learn

The system updates its internal metrics and refines future behaviour based on accumulated feedback.

Who: orchestrator + domain controllers.
Produces: updated AgentMetrics, adjusted strategy targets.

Agent Metrics Update

After each feedback entry, the agent's running metrics are updated:

These metrics are used to weight recommendations (higher accuracy = higher priority in conflict resolution), tune thresholds (high false positive rate → tighten finding rules), and report confidence (show users how reliable each agent's suggestions are).

Strategy Progress

1. Query latest observations matching the target metric
2. Update target.current to latest measurement
3. Recalculate target.progress = (current - baseline) / (goal - baseline)
4. If progress ≥ 1.0: strategy status → "completed"
5. If deadline passed and progress < 1.0: flag for review

Cycle Restart

The learn phase flows directly back to Strategise:

• Updated metrics inform which strategies need more attention
• Agent accuracy data adjusts which agents are preferred
• New observations may reveal new issues → new strategies

Data Flow Summary

User/System
  │
  ├─ POST /v1/strategy    → Strategy + StrategyTarget
  ├─ POST /v1/context     → EntityContext
  │
  ▼
Orchestrator
  ├─ Decomposes strategy into domain tasks
  ├─ POST /v1/task → Domain controller
  │
  ▼
Domain Controller
  ├─ Selects workflow based on task action
  ├─ Executes phases:
  │   ├─ POST /v1/message → Agent A → Observation + Recommendations
  │   ├─ POST /v1/message → Agent B → Observation + Recommendations
  │   └─ Self: aggregate results
  ├─ Returns TaskResult (changes, observations, recommendations)
  │
  ▼
Orchestrator
  ├─ Stores observations    (GET /v1/observations)
  ├─ Stores recommendations (GET /v1/recommendations)
  ├─ Logs audit entry       (GET /v1/audit)
  │
  ▼
Approval Gate
  ├─ Auto-approved or human-reviewed
  │
  ▼
Domain Controller (re-invoked)
  ├─ Applies accepted changes
  ├─ Waits for measurement window
  ├─ Re-observes → Feedback
  │
  ▼
Orchestrator
  ├─ Updates AgentMetrics
  ├─ Updates Strategy progress
  └─ Cycle restarts

Timing & Triggers

The lifecycle is not a single-threaded loop. Multiple cycles run concurrently, triggered by:

Implementation Notes

• Observation storage: observations SHOULD be stored with enough history for trend analysis. At minimum, keep the last 30 days.
• Feedback windows: after applying changes, wait before measuring. The window depends on the metric (SEO: 1–7 days, performance: minutes).
• Idempotent observations: running the same observation workflow twice on unchanged content should produce identical results.
• Metric aggregation: AgentMetrics are running aggregates, not recomputed from scratch each cycle. Use incremental formulas.
• Strategy decomposition: the orchestrator's mapping of strategies to domains can be rule-based (metric name → domain) or AI-assisted.
• Audit trail: every state transition (recommendation pending → accepted → applied → measured) MUST be logged for traceability.

Verification Checklist

• Strategies can be created and stored via POST /v1/strategy
• Orchestrator decomposes strategies into domain tasks
• Observations are recorded with measurements and findings
• Recommendations have priority, impact, and status
• Approval workflow transitions: pending → accepted/rejected → applied
• Feedback is collected after applying changes
• Feedback signal correctly reflects metric change direction
• AgentMetrics are updated after each feedback entry
• Strategy progress is recalculated from latest observations
• Completed strategies transition to "completed" status
• Multiple lifecycle cycles can run concurrently
• Full audit trail exists for every state transition