AI Guides Factory
An internal system for turning a guide idea into structured content, branded PDFs, privacy-safe screenshots, product listings, and marketing assets.
- Intended user
- A solo technical creator who wants a repeatable, reviewable production workflow instead of a collection of disconnected content tools.
- Current status
- Advanced internal prototype
- Used as an internal product-building system. It has no confirmed public deployment, external users, or sales.
Ownership
I originated and built this project from scratch, from the product idea and architecture through implementation. I use Claude Code and Codex as implementation tools; no human collaborator directed the work.
Architecture
A public-safe view of the system boundaries and the paths between them.
- Component 01Interface
Bundle brief
Scope, audience, deliverables, and acceptance criteria.
- Component 02Control
Supervisor
Owns task partitioning, shared files, integration, and the bounded worker budget.
- Component 03Agent
Research worker
Produces a source-backed research packet without editing buyer-facing output.
- Component 04Agent
Writing worker
Creates the guide and supporting assets from the approved brief and research.
- Component 05Agent
Independent review
Checks accuracy, edge cases, prose, visuals, and release risks separately from the writer.
- Component 06Data
Durable run state
Plans, task ledgers, learnings, research, and reviews make the workflow inspectable and resumable.
- Component 07Control
Readiness gate
Deterministic checks block incomplete bundles before integration or publication.
- Component 08Output
Reviewed bundle
Guide prose, PDFs, screenshots, product assets, listings, and marketing media.
Data and control paths
- Bundle briefSupervisor
- SupervisorResearch worker
- Research workerWriting worker
- Writing workerIndependent review
- SupervisorDurable run state
- Research workerDurable run state
- Writing workerDurable run state
- Independent reviewDurable run state
- Independent reviewReadiness gate
- Durable run stateReadiness gate
- Readiness gateReviewed bundle
Evidence boundary
What this case study establishes, and what it deliberately does not claim.
Verified evidence
Claims supported by inspected artifacts, repeatable checks, or the project's current state.
Bounded orchestration
The supervisor enforces concurrency, total-worker, and recursion-depth limits rather than allowing uncontrolled fan-out.
Basis: Private repository and orchestration documentation
Durable recovery
Run state is recorded in explicit plans, ledgers, research, reviews, and learning files, and dead worker processes can be reaped from the task ledger.
Basis: Private repository and synthetic control-path check
Maker-checker separation
Research, writing, and independent review are assigned as separate responsibilities, so the writer does not approve its own work.
Basis: Implemented orchestration workflow
Deterministic release controls
Readiness checks audit required artifacts and lifecycle state before a guide or bundle is treated as ready.
Basis: Private repository evidence
Known limitations
What has not been established, validated with users, or measured in production.
No external adoption
The system has no confirmed external users, customers, sales, or product-level outcome metrics.
Private implementation
The source remains private. This page presents public-safe architecture and synthetic control evidence only.
Partial evaluation scope
The published synthetic check covers task-ledger safeguards, not end-to-end content quality or autonomous agent performance.
Engineering decisions
The design choices, reasoning, and tradeoffs that shaped the system.
- 01
One supervisor owns integration
Workers receive disjoint file boundaries while shared state and merges remain under one supervisor.
Why: Central integration keeps parallel work predictable and makes ownership explicit.
Tradeoff: The supervisor can become a throughput bottleneck, but it prevents silent merge conflicts and unclear authority.
- 02
Bound fan-out at multiple levels
Cap concurrent workers, total workers, and recursion depth independently.
Why: A single limit does not protect against every runaway pattern or a worker spawning another worker.
Tradeoff: Some work waits in a queue even when a model could start immediately.
- 03
Persist context outside model sessions
Use explicit plan, state, research, learning, and review artifacts as the durable source of truth.
Why: An interrupted run can resume from inspectable state instead of reconstructing decisions from chat history.
Tradeoff: The file model adds reconciliation work and is a deliberate intermediate step before a database-backed task system.
- 04
Gate releases deterministically
Use objective artifact and lifecycle checks before subjective visual and editorial review.
Why: A successful agent run does not prove that a complete, safe, publishable product exists.
Tradeoff: The gate can verify completeness and consistency, but not whether the content is commercially valuable.
Reliability & safety
Controls that make failures visible, bounded, and recoverable.
- Failure handling
Dead-worker reaping
The task ledger marks a vanished worker as failed so a stale slot cannot deadlock the run.
- Failure handling
Isolated ownership
Parallel tasks use isolated worktrees and disjoint folders before supervisor-controlled integration.
- Safety boundary
Independent review
The workflow separates creation from approval and records reviewer findings for integration.
- Safety boundary
Dry-run-first reconciliation
Catalog changes are previewed at field level and protected lifecycle states require explicit override.
- Testing
Rendered-output review
PDF and video workflows require inspection of the rendered artifact, not just a successful command.
Synthetic evaluation
A reproducible, non-production signal with its methodology and limits attached.
Synthetic orchestration-control check
Three isolated checks exercised the task-ledger safeguards with temporary state and no guide, customer, or personal data.
Evaluation set: 3 synthetic control scenarios
- Control paths
- 3 / 3
- Dead worker
- Reaped
- Concurrency limit
- Blocked
- Total task limit
- Refused
Each synthetic scenario produced the expected deterministic safeguard.
The vanished worker was marked failed and the running count returned to zero.
The second task timed out while the single allowed slot remained occupied.
The ledger rejected a second registration after the one-task run budget was consumed.
Methodology
- 01Registered a synthetic worker with a nonexistent process identifier, then ran the reaper and inspected the ledger state.
- 02Held the only concurrency slot with a live process and attempted a second acquisition with a 150 ms deadline.
- 03Completed one task under a one-task total budget, then attempted to register another task.
Interpretation limits
- This is a small synthetic control-path check, not a production load test.
- It evaluates the task-ledger safeguards, not research accuracy, writing quality, or reviewer judgement.
- It does not establish external usage, reliability at scale, or business impact.
Current state
- State 01This is an advanced internal prototype rather than a publicly deployed product.
- State 02There are no confirmed external users, sales, or product adoption metrics.
- State 03The repository remains private while the workflow, architecture, synthetic artifacts, and public-safe implementation details can be discussed.
Demo & public material
Only reviewed, public-safe material is linked from this page.
- Public materialPublic
Architecture overview
The public-safe system flow and trust boundaries are shown here.
- Public materialPublic
Synthetic control check
Methodology, sample size, observed safeguards, and limitations are published on this page.
View public material - Public materialPlanned
Recorded walkthrough
A synthetic end-to-end walkthrough still needs privacy and licensing review before publication.
- Public materialNot public
Source repository
The repository is private. Architecture and selected public-safe evidence can be discussed without sharing source.
Next steps
- Next 01Prove the full workflow repeatedly across more guide bundles and record cycle-time and quality metrics.
- Next 02Promote bundle and task state into the local API after the file-based workflow is stable.
- Next 03Turn the strongest internal workflow into a smaller, clearly scoped product for external validation.