independent project · 03Agent-assisted publishing system
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.
01
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.
02
Architecture
A public-safe view of the system boundaries and the paths between them.
- interface
Bundle brief
Scope, audience, deliverables, and acceptance criteria.
- control
Supervisor
Owns task partitioning, shared files, integration, and the bounded worker budget.
- agent
Research worker
Produces a source-backed research packet without editing buyer-facing output.
- agent
Writing worker
Creates the guide and supporting assets from the approved brief and research.
- agent
Independent review
Checks accuracy, edge cases, prose, visuals, and release risks separately from the writer.
- data
Durable run state
Plans, task ledgers, learnings, research, and reviews make the workflow inspectable and resumable.
- control
Readiness gate
Deterministic checks block incomplete bundles before integration or publication.
- output
Reviewed bundle
Guide prose, PDFs, screenshots, product assets, listings, and marketing media.
- Bundle brief → Supervisor · plan
- Supervisor → Research worker · bounded task
- Research worker → Writing worker · evidence packet
- Writing worker → Independent review · candidate output
- Supervisor → Durable run state · persist
- Research worker → Durable run state
- Writing worker → Durable run state
- Independent review → Durable run state
- Independent review → Readiness gate · review findings
- Durable run state → Readiness gate · artifact inventory
- Readiness gate → Reviewed bundle · ready
03
Evidence boundary
What this case study establishes, and what it deliberately does not claim.
verified
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
not claimed
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.
04
Engineering decisions
The design choices, reasoning, and tradeoffs that shaped the system.
One supervisor owns integration
Workers receive disjoint file boundaries while shared state and merges remain under one supervisor.
rationaleCentral integration keeps parallel work predictable and makes ownership explicit.
tradeoffThe supervisor can become a throughput bottleneck, but it prevents silent merge conflicts and unclear authority.
Bound fan-out at multiple levels
Cap concurrent workers, total workers, and recursion depth independently.
rationaleA single limit does not protect against every runaway pattern or a worker spawning another worker.
tradeoffSome work waits in a queue even when a model could start immediately.
Persist context outside model sessions
Use explicit plan, state, research, learning, and review artifacts as the durable source of truth.
rationaleAn interrupted run can resume from inspectable state instead of reconstructing decisions from chat history.
tradeoffThe file model adds reconciliation work and is a deliberate intermediate step before a database-backed task system.
Gate releases deterministically
Use objective artifact and lifecycle checks before subjective visual and editorial review.
rationaleA successful agent run does not prove that a complete, safe, publishable product exists.
tradeoffThe gate can verify completeness and consistency, but not whether the content is commercially valuable.
05
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.
06
Synthetic evaluation
Three isolated checks exercised the task-ledger safeguards with temporary state and no guide, customer, or personal data.
Synthetic orchestration-control checksynthetic · not production or customer data
- Control paths
- 3 / 3
- Each synthetic scenario produced the expected deterministic safeguard.
- Dead worker
- Reaped
- The vanished worker was marked failed and the running count returned to zero.
- Concurrency limit
- Blocked
- The second task timed out while the single allowed slot remained occupied.
- Total task limit
- Refused
- The ledger rejected a second registration after the one-task run budget was consumed.
set · 3 synthetic control scenarios
method · Registered a synthetic worker with a nonexistent process identifier, then ran the reaper and inspected the ledger state. Held the only concurrency slot with a live process and attempted a second acquisition with a 150 ms deadline. Completed one task under a one-task total budget, then attempted to register another task.
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.
07 – 09
State, material, next
current state
- This is an advanced internal prototype rather than a publicly deployed product.
- There are no confirmed external users, sales, or product adoption metrics.
- The repository remains private while the workflow, architecture, synthetic artifacts, and public-safe implementation details can be discussed.
demo & public material
- Architecture overviewavailable
The public-safe system flow and trust boundaries are shown here.
- Synthetic control check ↗available
Methodology, sample size, observed safeguards, and limitations are published on this page.
- Recorded walkthroughplanned
A synthetic end-to-end walkthrough still needs privacy and licensing review before publication.
- Source repositorynot public
The repository is private. Architecture and selected public-safe evidence can be discussed without sharing source.
next steps
- 01Prove the full workflow repeatedly across more guide bundles and record cycle-time and quality metrics.
- 02Promote bundle and task state into the local API after the file-based workflow is stable.
- 03Turn the strongest internal workflow into a smaller, clearly scoped product for external validation.