Agent Catalog

The execution layer — agents bring blueprint specifications to life as autonomous services. Every agent implements the same 5 protocol endpoints (describe, execute, health, message, services) and communicates via Ed25519-signed messages. The developer implements only the custom logic — the framework handles registration, messaging, and security.

Agent Architecture

Weblisk distinguishes three kinds of agents. Each kind implements the same protocol but serves a different role in the system:

Business tasks flow: Orchestrator → Domain Controller → Work Agents. Infrastructure agents are available to any authenticated caller. Work agents do not accept tasks from arbitrary sources — only from their owning domain.

Agent Logic Interface

Every agent implements two methods:

• Execute(task, context) → result — The agent's core intelligence. Receives a task with full runtime context (identity, services, LLM provider, workspace). Returns status, summary, proposed changes, and metrics.
• HandleMessage(message, context) → response — Handles direct messages from other agents. Used for collaboration and queries.

Protocol Endpoints

Every agent exposes these 5 HTTP endpoints:

Port Assignment Convention

Domain Controllers

A domain controller is the business intelligence layer — it sits between the orchestrator and work agents. It receives business-level tasks, selects the matching workflow, dispatches phases to target agents, aggregates results, and enforces quality gates. Nothing enters or leaves a business function without the domain controller's knowledge.

Execution Flow

1. Domain registers with the orchestrator, declaring required_agents and workflows
2. Orchestrator routes a business task to the domain
3. Domain resolves the workflow DAG — phases at the same dependency level execute concurrently
4. Domain dispatches each phase to the target agent and aggregates all results into a single TaskResult

Workflow DAG specifications (phase dependencies, reference expressions, approval gates) are defined in the workflow blueprint pattern.

Current Domains

Infrastructure Agents Free

System-level services available to all domains and authenticated agents. Ship with every Weblisk server.

sync

Bridges offline-capable clients with the server's persistent store. Clients accumulate changes in IndexedDB while offline and push them when connectivity resumes. The agent also runs on schedule to pull server-side changes and push them to connected clients via real-time channels.

Capabilities & Triggers

Triggers: client.sync.push (client pushes offline changes) · Schedule: */5 * * * * (pull server changes every 5 min)

Configuration

config:
  conflict_resolution: last-write-wins   # last-write-wins | client-wins | server-wins | manual
  batch_size: 100                        # max records per sync batch
  sync_interval: 300                     # seconds between scheduled syncs
  max_payload_size: 1048576              # 1 MB max per push

Conflict Resolution Strategies

Actions: sync_push (push offline changes), sync_pull (pull server changes since checkpoint), get_status (connected clients, pending conflicts)

cron

Scheduled task execution with cron-style expressions. Other agents and application code register tasks; the cron agent evaluates schedules, dispatches tasks at the correct time, tracks results, and retries failed tasks.

Capabilities & Triggers

Triggers: Schedule: * * * * * (tick every minute) · cron.register (new task) · cron.cancel (task cancelled)

Configuration

config:
  tick_interval: 60              # seconds between schedule checks
  max_retries: 3                 # default retries per task
  retry_backoff: exponential     # fixed | exponential
  max_concurrent: 10             # max tasks executing simultaneously
  history_retention: 604800      # 7 days in seconds

Cron Expression Format

┌───────── minute (0-59)
│ ┌───────── hour (0-23)
│ │ ┌───────── day of month (1-31)
│ │ │ ┌───────── month (1-12)
│ │ │ │ ┌───────── day of week (0-6, 0=Sunday)
│ │ │ │ │
* * * * *

Actions: register (schedule a task), cancel, list (active tasks), history (execution log), pause / resume. For one-time tasks, use "once" with a fire_at timestamp.

webhook

Runtime counterpart to the webhook-inbound and webhook-outbound blueprints. While those blueprints define the API surface, this agent handles the asynchronous work: verifying inbound signatures, routing events to handlers, sending outbound webhooks with retries, and tracking delivery status.

Capabilities & Triggers

Triggers: webhook.received (inbound webhook) · webhook.send (outbound event) · Schedule: */1 * * * * (retry failed deliveries). Collaborates with: cron agent.

Actions: process_inbound (verify signature, route to handler), send_event (queue outbound delivery to subscribers), register_subscriber, list_subscribers, delivery_status

email-send

Transactional email with template rendering, queuing, and delivery tracking. Other agents and application code send messages to this agent, which renders templates, queues emails, delivers via the configured provider, and tracks delivery status.

Capabilities & Triggers

Triggers: email.send (application requests email) · Schedule: */1 * * * * (process queue, retry failures). Collaborates with: cron agent.

Configuration

config:
  provider: smtp                 # smtp | sendgrid | ses | mailgun
  from_address: noreply@example.com
  from_name: My App
  queue_batch_size: 50           # emails per processing cycle
  max_retries: 3
  retry_backoff: exponential     # 1m, 2m, 4m
  rate_limit: 100                # max sends per minute

Template System

Simple mustache-style variable substitution: Hello {{name}}, your order #{{order_id}} has shipped. Templates are stored in the database and versioned. No logic — pure substitution.

Actions: send (queue email with template + variables), send_raw (send with raw HTML body), status (check delivery), register_template, list_templates

workflow

Owns the workflow execution engine. Receives workflow.trigger events, resolves DAG definitions from source domains, dispatches phases via task.submit events, tracks execution state, and publishes workflow.completed back to the invoker.

Port: 9780 · Triggers: workflow.trigger (start workflow) · task.complete / task.failed (phase result)

Actions: trigger (start a workflow run), status (execution state), cancel, list (active runs), history

task

Owns task dispatch and tracking. Receives task.submit events, dispatches work to target agents via POST /v1/execute, tracks completion, and publishes task.complete or task.failed back to the requester.

Port: 9781 · Triggers: task.submit (new task) · Schedule: */1 * * * * (retry stale tasks)

Actions: submit (dispatch task), status, cancel, list (pending tasks), history

lifecycle

Owns the continuous optimization loop. Manages strategies, entity context, observations, recommendations, approvals, feedback, and agent metrics. Subscribes globally (scope: "*") to workflow completion events to capture results across the entire hub.

Port: 9782 · Triggers: workflow.completed (capture results) · Schedule: 0 * * * * (hourly strategy evaluation)

Actions: observe (record observation), recommend (generate recommendations), approve / reject, feedback, strategies (list active strategies)

alerting

Receives alert events from the orchestrator, domain controllers, and other agents, then routes notifications to the appropriate channels based on severity, source, and subscriber preferences.

Port: 9752 · Depends on: email-send · Triggers: alert.fire (new alert) · alert.resolve (alert cleared)

Actions: fire (create alert), resolve, acknowledge, subscribe (register subscriber), rules (manage routing rules), history

incident-response

Automated incident detection, runbook execution, remediation steps, and post-incident reporting. Works alongside the alerting agent — alerting handles notification routing, incident-response handles what to do about it.

Port: 9760 · Depends on: alerting · Triggers: incident.detected (new incident) · alert.fire (escalated alert)

Actions: detect (create incident), execute_runbook, escalate, resolve, postmortem (generate report), list (active incidents)

health-monitor

Internal infrastructure health monitoring for a Weblisk hub. Tracks agent liveness, orchestrator health, domain controller status, storage latency, federation peer reachability, and gateway responsiveness. Unlike the health domain controller (which monitors external endpoints), this agent monitors the hub itself.

Port: 9755 · Depends on: alerting · Triggers: Schedule: */1 * * * * (continuous health checks)

Actions: check (run health check), status (current health snapshot), baselines (view/update baselines), history

hub

Unified hub infrastructure agent for the Weblisk hub network. Handles indexing, search, metrics, verification, and alerting across the federated catalog of published capability listings.

Port: 9770 · Triggers: hub.publish (new listing) · hub.search (query catalog) · Schedule: 0 */6 * * * (federation sync)

Actions: publish (register listing), search (query catalog), verify (validate listing), metrics (usage stats), sync (federation peer sync)

Work Agents Free

Specialized agents dispatched by domain controllers. Each agent serves a specific business function. They register with the orchestrator but business tasks route through their owning domain.

SEO Domain

seo-analyzer

Scans HTML files, extracts metadata, analyzes quality via LLM, validates findings against rules, and proposes changes. Dispatched by the SEO domain controller.

Actions: scan_html (extract metadata — title, description, headings, images, OG tags, canonical), analyze_metadata (LLM-powered analysis with recommendations), generate_report (unified SEO report with scores and proposed changes), review_seo (quick review of content without LLM)

a11y-checker

Validates accessibility compliance — ARIA roles, color contrast, alt text, focus management, and WCAG guidelines. Dispatched by the SEO domain controller.

Actions: check_images (validate alt text presence and quality), check_contrast (color contrast ratios), check_aria (ARIA roles and landmarks), full_audit (comprehensive WCAG check)

Content Domain

content-analyzer

Measures readability (Flesch-Kincaid), heading structure, paragraph balance, and content quality signals. Dispatched by the Content domain controller.

Actions: analyze_readability (Flesch-Kincaid score, sentence complexity), check_structure (heading hierarchy, paragraph balance), grade_quality (content signals and engagement metrics)

meta-checker

Validates HTML metadata completeness — Open Graph, Twitter Cards, structured data (JSON-LD), and canonical URLs. Dispatched by the Content domain controller.

Actions: check_og (Open Graph tags), check_twitter (Twitter Card tags), check_jsonld (structured data validation), check_canonical (canonical URL presence and correctness)

Health Domain

uptime-checker

Checks endpoint availability, response time, DNS resolution, and TLS certificate status with grading. Dispatched by the Health domain controller.

Actions: check_endpoint (HTTP response time and status), check_dns (DNS resolution and propagation), check_tls (certificate validity, expiry, chain), grade (composite health grade)

perf-auditor

Measures page load performance, Core Web Vitals (LCP, FID, CLS), resource budgets, and optimization opportunities. Dispatched by the Health domain controller.

Actions: measure_vitals (LCP, FID, CLS), check_budgets (resource size budgets), audit_performance (full performance audit with recommendations), compare (before/after comparison)

Pro Agents

Available through Weblisk Pro or via Avaropoint for enterprise engagements.

Concurrency & Backpressure

Every agent enforces a maximum number of concurrent executions. When at capacity, agents return 429 Too Many Requests with a Retry-After header.

Domain controllers respect agent capacity by tracking in-flight requests and queuing excess work. After 3 consecutive 429s for the same agent, domains degrade gracefully — serializing remaining phases instead of parallel dispatch.