Three workload families, each ending in an output a reviewer can check.
Each workload pairs a concrete input with an explicit multi-step loop. All three run on the same control plane for identity and access, audit, evaluation, FinOps, and reliability.
Codebase intelligence
Understand a repository before changing it. The system maps structure and dependencies, reads tests and build output, plans the change, produces a patch in an isolated workspace, and explains the evidence behind it.
Where it applies
- Migrations and upgrades — framework, language, and dependency changes across many modules
- Root-cause investigation — tracing a failure across services, logs, and recent changes
- Architecture Q&A — answers grounded in file- and line-level citations
- Test expansion — coverage for under-tested paths, validated by running the suite
Pipeline repo → reviewed patch
Ingest
Check out a pinned commit; index files, symbols, build configuration, ownership, and CI history.
Map
Build dependency and call graphs; locate tests, entry points, and the blast radius of the intended change.
Plan
Write a change plan tied to specific files, with acceptance checks defined before any code is generated.
Change & test
Generate the patch in a sandboxed branch; run formatters, type checks, and the relevant test suites.
Explain & review
Deliver a review package — diff, test output, rationale, residual risks. Merge requires a human approver.
Inputs
- Repositories and history
- Issues and tickets
- CI and build logs
- Architecture documents
Outputs
- Patch with test evidence
- Impact analysis
- Migration plans
- Cited codebase answers
Controls
- Read-only by default
- Writes confined to a sandbox branch
- Secret scanning on context
- No merge without approval
Evaluated by
- Tests passing on held-out tasks
- Reviewer acceptance rate
- Post-merge regression rate
- Cost per accepted change
Long-document evidence processing
Turn long filings, contracts, policies, and technical reports — including their tables, figures, and attachments — into cited findings, structured records, and specific questions for a reviewer.
Where it applies
- Regulatory and policy review — mapping obligations to evidence and flagging gaps
- Contract analysis — clause extraction, deviation from standard terms, cross-document conflicts
- Technical due diligence — reconciling figures across reports, appendices, and data tables
- Structured data capture — schema-bound records with every field traceable to a source span
Pipeline documents → cited brief
Intake
Parse PDFs, scans, spreadsheets, and attachments while preserving page, table, and figure coordinates.
Structure
Segment into sections, clauses, and tables; normalize entities, dates, currencies, and units.
Extract
Populate fields and findings against an agreed schema, each bound to the exact source span that supports it.
Cross-check
Reconcile figures across documents; surface contradictions, missing items, and out-of-policy terms.
Brief & review
Produce a cited brief and a review queue ordered by risk and confidence. Reviewers confirm or correct each item.
Inputs
- Filings and disclosures
- Contracts and policies
- Technical reports
- Scanned exhibits and tables
Outputs
- Cited briefs
- Records (JSON / CSV) with spans
- Discrepancy reports
- Prioritized review queue
Controls
- Claim → page and span, always
- Unsupported statements flagged, never presented as findings
- Access inherited from source
- Retention set per matter
Evaluated by
- Citation precision
- Field-level accuracy on labeled sets
- Recall of seeded discrepancies
- Reviewer time per document
Long-running tool orchestration
Coordinate multi-step work across applications and APIs — with explicit plans, scoped tools, checkpoints, bounded retries, and human gates — so long processes finish reliably and leave a complete trail.
Where it applies
- Cross-system requests — work that touches ticketing, records, and line-of-business applications
- Runbook execution — operational procedures with verification after every step
- Exception handling — triage, evidence gathering, and a hand-off with the context attached
- Periodic close-out work — reconciliations and checklists that span hours, not seconds
Pipeline request → closed run
Intake
Accept a request with its objective, constraints, data scope, and named approvers.
Plan
Compile the request into a task graph with dependencies, per-step tool permissions, and step and spend budgets.
Execute
Run steps through a scoped tool executor using idempotent calls and bounded retries with backoff.
Checkpoint
Persist state after each step so a run resumes after failure without repeating side effects.
Approve & close
Route consequential writes to a human gate; close the run with a complete, replayable record.
Run record
Inputs
- Requests via ticket, email, or API
- Application and data APIs
- Runbooks and policies
- Approval matrices
Outputs
- Closed runs
- Replayable run records
- Exception reports
- Clean human hand-offs
Controls
- Per-tool allowlists and scopes
- Step and spend budgets
- Approval gates on writes
- Per-run kill switch
Evaluated by
- Task completion rate
- Human intervention rate
- Side-effect correctness
- Time and cost per run
Comparison: different inputs, one discipline.
The workloads differ in what they read and what they produce. They share the same control plane and the same rule: nothing consequential leaves the system without evidence and an approver.
| Dimension | Codebase intelligence | Long-document evidence processing | Long-running tool orchestration |
|---|---|---|---|
| Primary context | Source, tests, build and CI output | Long documents, tables, figures | Live system state via APIs |
| Core loop | Map → plan → change & test | Structure → extract → cross-check | Plan → execute → checkpoint |
| Primary artifact | Reviewed patch with test evidence | Cited brief and records | Closed run with replayable record |
| Human gate | Merge approval | Reviewer confirmation | Approval on consequential writes |
| Key quality signal | Accepted changes without regression | Citation precision | Side-effect correctness |
Next step
Have a workload that fits one of these shapes?
Send a short description of the inputs, steps, and reviewed result. If it fits our scope, the next step is a working session with the people who own the work.