LiveDaily intelligence for people building software in the AI era. It filters product news, technical change, and informed opinion down to what materially changes how builders ship.
Agentic AI · Editorial pipeline
Automated daily, reviewed weekly.
BuilderWithin and WPWithin are independent publications I designed and operate end to end on a multi-model agentic system. It verifies candidates against primary sources, drafts, reviews against editorial policy, and releases on a schedule without supervision. Most of what it considers never ships.
Independent work, built and run on my own time. I am a product manager on agentic AI products by day.
2
Publications operated
5
Pipelines, one queue
Daily
Unattended releases
1 in 19
Candidates that ship
The publications
Live
LivePractical WordPress intelligence for site owners, agencies, and hosting professionals. It turns important ecosystem, security, and product developments into clear guidance for people running sites day to day.
Selective by design
Generating articles was never the hard part. The hard part was building something that decides, reliably and without supervision, what should not exist. Most candidates are rejected, and the gates that reject them are the actual product.
Editorial pipeline
- 01IntakeSources are collected behind per-host circuit breakers, deduplicated, filtered under a fixed budget, and traced back to the primary source.
- 02SelectionAudience fit, editorial policy, and recent coverage decide what proceeds. Most candidates end here.
- 03Research and draftingA multi-agent workflow orchestrates research, drafting, and review, verifying claims against primary sources as it goes. Role prompts, scoped tool permissions, and expected output contracts bound what each agent can do, and distinct models are routed to the work each suits.
- 04ValidationAutomated evals cover editorial accuracy, factual grounding, and structural conformance, and run as hard gates. Only the weekly lane gets one bounded repair attempt, and it faces the same gate afterwards.
- 05Automated releaseThe daily lanes release unattended. Every run tests its own tooling before it starts, the whole site has to build, and the shared release queue revalidates from scratch on every conflict rather than retrying a stale result. Continuous integration re-runs on main behind the push as a safety net.
- 06Reviewed releaseThe weekly issue opens as a draft for human-in-the-loop review. Continuous integration gates the pull request alongside it, and the send runs only once the reviewed article is confirmed live, and only ever once.
- ··Context assemblyEditorial policy, audience definition, and recent coverage are assembled into the working context before any model sees a candidate. This is the context engineering layer every later decision reads from.
- ··Execution checkThe agent’s own run log is checked before any prose is evaluated. A missing or errored result stops the pipeline. Hitting the turn limit is passed through instead, for validation to judge on the output itself.
- ··TelemetryEvery run records its own cost, decisions, permission denials, and failures, including the runs that publish nothing.
Sampled over 84 automated BuilderWithin runs, 8 July to 6 September 2026. WPWithin runs the same design and rejects a comparable share. The dashed paths are conditional: the fallback lane runs only when the primary filter is unavailable, and the repair attempt exists only on the reviewed lane.
What the system will not do
The writer cannot publish
The drafting agent runs under an explicit permission contract with commit and release denied. Publication is a separate step it has no path to reach.
A failed check publishes nothing
Validation gates every run. Work that does not pass is discarded, never revised until it slips through.
No newsletter goes out unreviewed
The weekly issue opens as a draft for human review. Sending is a deliberate manual step, taken against the article already live in public.
Every run is inspectable
Each execution records its own cost, decisions, permission denials, and failures, so quality is audited rather than asserted.
Why I built it this way
Three decisions shaped the rest of the system. Each traded convenience for something I was not willing to give up.
Rejection has to be cheap
A failed check discards the work instead of sending it back for another attempt. A retry loop optimises for passing the gate rather than for being right, and I would rather lose a story than teach the system to argue its way through one.
Route by fit, degrade without trust
Distinct models take the work each suits. When the primary path is unavailable a smaller one stands in, but nothing it produces is trusted on its own. The guardrail is a grounding check that discards anything it cannot match back to real source material.
Reproducible or it did not happen
Every action, dependency, and image is pinned to an exact version, so the supply chain cannot shift under a run. Each run then writes a full record of what it did, what it refused, and what it cost. A system that publishes under my name without supervision has to be reconstructable afterwards, not just observable while it runs.
Want to compare notes?
On the publications, the numbers, or what's next.
© 2026 James Lee · All rights reserved. · Privacy Policy