Forge Platform

Handbook

Micro-Agents and Micro-Packs

Forge's micro-agent idea is innovative because it resists the impulse to turn every task into a large, open-ended agent loop. A micro-agent is a bounded local-LLM run for a single judgment task using a fixed micro-pack.

Updated

Core Thesis

Forge's micro-agent idea is innovative because it resists the impulse to turn every task into a large, open-ended agent loop. A micro-agent is a bounded local-LLM run for a single judgment task using a fixed micro-pack.

The key idea is: use the smallest agent that can responsibly make the judgment.

Condensed Thought

Some tasks do not need a full autonomous coding agent. They need a focused judgment: inspect one UX rule, classify one finding, evaluate one evidence slice, or apply one discipline lens to one artifact. Forge micro-agents are designed for that kind of bounded work.

A micro-agent uses a micro-pack with a manifest and fixed prompt, assembled context, a local_llm_worker, LCDL chat, model output, logs, and a detection gate. The MVP intentionally avoids vector databases and MCP, keeping the execution path inspectable.

Why It Stands Out

This is a cost-aware and risk-aware agent pattern. Instead of assuming bigger loops are better, Forge creates a path for small, repeatable, local judgment cells. That can reduce token cost, reduce blast radius, improve testability, and make evidence easier to review.

Micro-agents also fit the workcell philosophy. They are bounded workcells that return reviewable output rather than owning delivery state.

Forge Ecosystem Hooks

  • Micro-pack contains manifest, prompt, and context schema.
  • forgesdlc-kitchensink can assemble context for UX auditor use cases.
  • forge-workcells can host the local_llm_worker runner.
  • LCDL provides governed model calls.
  • AgentRun and WorkcellRequest/Result connect the micro-agent to ForgeRun.
  • EvidencePacket can include findings, logs, model output, and detection gate results.

Architecture Implications

Micro-agents need strong boundaries:

  1. One judgment task per run.
  2. Fixed prompt and manifest in a versioned micro-pack.
  3. Explicit context schema.
  4. No hidden retrieval in the MVP unless deliberately introduced later.
  5. Output parsing and detection gates.
  6. Logs and artifacts linked to AgentRun and ForgeRun.
  7. Clear owner for each pack and runner.
  8. Benchmarks or fixtures to test whether the micro-agent improves detection quality.

This pattern can scale horizontally: many small judgment cells instead of one giant agent brain.

Blog Post Seed Paragraph

Agentic systems often get larger than the task requires. A single judgment can become a sprawling loop with broad context, tool access, retrieval, and unclear authority. Forge's micro-agent pattern moves in the opposite direction. A micro-agent performs one bounded judgment task using a fixed micro-pack, assembled context, governed LCDL call, and parseable output. It is small enough to inspect, test, and attach as evidence.

Risks And Counterarguments

Micro-agents can create fragmentation if every small task invents its own pack, output shape, and scoring method. Forge should standardize pack structure, output schemas, and evidence attachment while allowing domain-specific prompts.

Who this is for

Architects and platform engineers evaluating Forge (evaluate stage). Executives can stop after the core thesis; agents should honor the agent contract in the page frontmatter.

Evidence and maturity

Maturity: defined — this page records design intent captured from the Agentic SDLC standout analysis and reviewed for the platform handbook. Where behavior is shipped and observable it is called out explicitly; everything else should be read as direction, not commitment. Evidence trail: the hydration pack seed, the content registry entry for this content_id, and the claim registry entries linked via claim_ids.

How to use this page

  • Evaluating Forge? Read the core thesis and ecosystem hooks, then continue with the standout index.
  • Designing against the platform? Verify boundaries in the platform reference architecture before implementation.
  • Automating? Use the frontmatter agent_contract and cite content_id in generated output.

Agent contract

Allowed actions
  • summarize this page for evaluation questions
  • cross-reference claims via claim_ids and source_refs
Safe to infer
  • the architectural boundary described here is the intended design
Do not infer
  • production readiness beyond the stated maturity level
  • specific vendor, customer, or benchmark commitments
Key artifacts
  • forge-platform/docs-governance/content_registry.yaml

Machine-readable guidance from this page's frontmatter: what automated consumers may do, infer, and must not infer.