Skip to content
Agent Capability Catalogue

Source-backed knowledge

Problems, limits and supporting capabilities

Agent-readable problem and limitation summaries derived from catalogue records. No filler articles or unsupported claims.

Agent Architecture

Problems addressed

  • Live systems built from loosely connected schedulers, queues, and conversational loops can duplicate side effects, lose state, or become unsafe during big-bang orchestration rewrites.

Stated limitations

  • Not a greenfield rewrite
  • Never allow two authoritative owners for the same external effect
  • Do not infer completion from graph code or compilation alone
  • Prefer existing runtime architecture unless a graph dependency already fits

Agent Governance

Problems addressed

  • Agents can misclassify permission or configuration failures as missing capabilities and expand their own authority instead of stopping or improving safely.
  • Agent behaviour files can describe permissions or capabilities that the actual runtime does not enforce, leaving documentation and execution authority out of sync.

Stated limitations

  • Missing permission is not missing capability
  • Blocked agents cannot approve their own expansion
  • Implementation and activation are separate
  • Forbidden work remains forbidden

Agent Operations

Problems addressed

  • Repeatedly asking an LLM to keep going does not create durable autonomy, state ownership, recovery, duplicate prevention, or evidence-led continuation.

Stated limitations

  • A cron job repeatedly calling an LLM is not sufficient
  • No blanket authority for consequential actions
  • Do not generate work from imagination when evidence is missing
  • Do not learn from unverified outcomes

Agent Security

Problems addressed

  • Consequential agent actions can blur proposal, approval, execution, verification, and proof into one trust boundary, making replay and false-success risks difficult to audit.

Stated limitations

  • Protect one bounded action first rather than claiming generic tool security
  • Approval and receipt-signing key material must remain separate
  • Executor claims are not sufficient verification
  • Development process separation is not an OS sandbox

Agent Workflows

Problems addressed

  • Long-running coding agents can lose durable task state, repeat completed work, broaden scope, or claim completion without repository-owned evidence.

Stated limitations

  • Not a general autonomous daemon
  • Chat history is not authoritative workflow state
  • Autonomy does not imply permission to deploy, push, publish, or expand scope

Developer Tooling

Problems addressed

  • Static checks and local command success can be mistaken for production readiness, while skipped or unavailable evidence is often collapsed into false confidence.
  • A library can pass source typechecking and runtime builds while publishing declarations or exports that reference private workspace or dev-only dependencies unavailable to consumers.

Stated limitations

  • Read-only by design must be enforced
  • Skipped is not failed
  • Unverified is not safe
  • Configured is not running

Developer Workflows

Problems addressed

  • A document reader can hide distinct transport, authentication, response-size and validation failures behind one error, while a zero process exit or successful preview can be mistaken for a repaired live collector.
  • Open-source contributions can waste maintainer time or damage contributor credibility when they duplicate active work, solve the wrong layer, skip reproduction, misread CI, or present weak evidence as completion.

Stated limitations

  • Network configuration changes require route evidence and do not universally resolve WSL failures
  • A WSL shutdown affects all running distributions and must account for their active work
  • Retries remain bounded and confined to eligible transient token-refresh failures
  • The existing response byte cap and document integrity checks remain in force

Frontend Verification

Problems addressed

  • A dashboard can render correctly once while later events update detached nodes, leave hidden views stale, reset the reader's state, or confuse collection failures and missing data with healthy zero values.

Stated limitations

  • Synthetic browser evidence does not prove live collector or provider health
  • Known zero, blocked, stale, unknown, and collection failure remain distinct
  • A replacement node matching a selector does not prove original target continuity
  • Desktop, mobile, reconnect, and replay coverage are claimed only when exercised

Marketing Systems

Problems addressed

  • Marketing can become generic, manipulative, or feature-led when it assumes personal knowledge, invents outcomes, or pushes people through a hidden funnel.

Stated limitations

  • Do not invent customer results or guaranteed outcomes
  • Do not create fake urgency or superiority claims
  • Do not pretend to know the reader personally
  • Do not generate mass cold outreach

Production Operations

Problems addressed

  • A confident but incorrect production inventory can be more dangerous than an incomplete one, especially when stale documentation is treated as authoritative.

Stated limitations

  • No repair, restart, reload, install, update, migrate, delete, publish, rotate, or reconcile
  • Runtime and provider evidence outrank documentation
  • Unavailable or unverified components cannot be reported healthy
  • Preserve contradictions rather than editing them away

Production Reliability

Problems addressed

  • External API calls can return ambiguous or misleading local success while the provider-side effect is absent, duplicated, delayed, or unknown.
  • Scheduled workers and queued jobs can change state during a release, while interrupted switches, automatic catch-up work, and slow diagnostics can make repeated upgrades or premature success claims unsafe.

Stated limitations

  • Successful local execution is not provider success
  • Ambiguous evidence remains unresolved
  • Live diagnostic writes must be explicitly authorised
  • Repair must not create duplicates

Publication Reliability

Problems addressed

  • Schedulers and provider write responses can be mistaken for publication truth, while blind retries can create duplicate external effects.

Stated limitations

  • Official provider readback is publication truth
  • Ambiguous writes are not blindly retried
  • Content models do not choose product, campaign, account, connector, or approval
  • One scheduler owner controls a slot