Search docs...⌘/
Search docs...⌘/
DocsADRsADR-003: Worker Plugins as AI Tools
ADR-003: Worker Plugins as AI Tools
Architectural Decision Record 3 mapping core software structure decisions.
Status
Proposed
Context
LeadForge OS has a robust background execution engine. Spawning heavy Puppeteer or Cheerio tasks directly inside the agent's main thread would block the main process, saturate the CPU, and bypass scheduling constraints. We need a way to expose these tasks to the AI agent as tools while keeping them isolated.
Decision
We will wrap the existing worker plugins (such as Maps Scraper, Crawler, LinkedIn Enricher, and SMTP outreach) as AI Tools:
- Asynchronous Dispatch: The tool's
executemethod submits a job to theJobScheduler. - Result Polling: The tool polls the database or listens to the scheduler's completion events.
- Execution Isolation: The actual work runs in a sandboxed child process, keeping the agent process light.
No duplicate scheduling, heartbeat, retry, or recovery code will be written.
Alternatives Considered
- Direct Execution: Run Playwright and Cheerio directly within the agent's thread.
- Tradeoffs: Simplifies execution flow, but blocks the main Electron UI, increases memory usage, and bypasses concurrency limits.
- Duplicate AI Scheduler: Create a separate scheduler specifically for AI agent tasks.
- Tradeoffs: Unnecessary complexity and increases the risk of database write locks.
Tradeoffs
- Pros:
- Process Stability: Sandboxing heavy tasks protects the main desktop shell.
- Feature Reuse: Leverages heartbeats, retries, checkpointing, and recovery out of the box.
- Queue Limits: Agent-driven tasks respect workspace CPU limits.
- Cons:
- Adds small database polling latency to tool executions.
Consequences
- The Agent Platform does not spawn child processes directly. It interacts only with the
JobScheduler. - Heavy worker tasks must return unified JSON result payloads to be consumed by the agent.