Project 04 · Agentic publishing
Knowledge Publishing Agent
A specified, not-yet-built agent that decides which stage a document actually needs.
Specified; Phase 2 of the development roadmap
Mission
Remove the need for a person to decide every next publishing step, without removing the person from publication authority.
Problem
The Project 01 workflow worked, but a person had to decide every next step. Many documents do not need every stage: some already have clean formatting, some are missing metadata, some have broken links. A fixed sequence cannot tell the difference.
Constraints
- This is a design I have specified but not yet built.
- Document content is treated as untrusted input.
- Content generation is kept structurally separate from publishing authority.
- Deterministic code — not model judgment — runs required-field, structure, link, and style checks.
My role
I have defined the agent’s responsibilities, its state model, the tool allowlist boundary, the validation and retry behavior, and the approval and audit requirements. Building it is Phase 2 of my development roadmap.
Architecture
The agent inspects source content and classifies article type, detects missing sections and broken links, and selects only the approved templates and transformation tools that condition requires. Retry is bounded. Publication is a human decision.
Inspect document
Untrusted input
Classify state
Article type, gaps
Choose tool
From allowlist
Validate output
Deterministic checks
Request approval
Publish
Correct / retry
Bounded
Safe stop / escalate
Audit log
Tools, decisions, retries, disposition
- Inspect document
- agent — Untrusted input
- Classify state
- agent — Article type, gaps
- Choose tool
- agent — From allowlist
- Validate output
- validation — Deterministic checks
- Correct / retry
- tool — Bounded
- Safe stop / escalate
- policy
- Request approval
- approval
- Publish
- output
- Audit log
- data — Tools, decisions, retries, disposition
AI architecture
- Agent
- State classification and tool selection inside an allowlist
- Tool
- Approved templates and transformation tools only
- Validation
- Deterministic code for required fields, structure, links, style
- Human interaction
- Approval before publication
Security architecture
- Untrusted input
- Prompt-injection resistance; tool policy overrides content
- Least privilege
- Allowlisted tools and constrained service identity
- Safe failure
- Enforced retry limits and stop conditions
- Accountability
- Audit trail plus versioned output artifacts
Build process
- Specified responsibilities, state model, allowlist, validation, retry, approval, and audit.
- Not implemented. Planned validation includes happy-path guides, malformed documents, prompt-injection in source content, tool-failure, and safe-stop cases.
Validation
Planned validation
Known-good guides, malformed/incomplete documents, prompt-injection attempts, tool-failure and retry-limit cases
Specified: the agent must stop safely instead of guessing. Not yet executed — this remains a design.
| Check | Method | Result |
|---|---|---|
| Planned validation | Known-good guides, malformed/incomplete documents, prompt-injection attempts, tool-failure and retry-limit cases | Specified: the agent must stop safely instead of guessing. Not yet executed — this remains a design. |
Challenges
“Human in the loop” is easy to write and easy to bypass if the loop is only a prompt instruction.
Investigation
The Project 01 workflow proved the stages. It also proved that a person was still the scheduler. The design question became how to give the system path-selection without giving it publication authority.
Resolution
A state machine that enforces approval, with deterministic checks for anything that must be correct.
Lessons
Enforced loops, not requested loops
Designing this clarified that “human in the loop” only means something when a state machine enforces it. Probabilistic model judgment is for interpretation; deterministic code is for anything that must be correct.
Cybersecurity equivalent
- Tool allowlistmaps toAuthorized capability boundary
- Human approval before publishmaps toPrivileged change control
- Untrusted document contentmaps toUntrusted-input handling / prompt-injection resistance
AI principles applied
Agentic workflows
Inspect state, select approved actions, manage retries, adapt the path. Still not autonomous.
Where learned: Specified in the publishing agent; built in the home-lab triage agent.
Tool use and allowlists
Tools are capabilities. If it is not on the allowlist, completing the task “the easy way” is a failed control.
Where learned: Triage red-team included privilege-escalation prompts that would have been easier with extra tools.
Human-in-the-loop
Consequential actions require a person. The loop is a state machine, not a polite request in a prompt.
Where learned: Publishing, packaging, containment, and deploy all use explicit gates.
Authority boundaries
Collection, analysis, and remediation are different privileges. Drafting and publishing are different privileges.
Where learned: Triage and Basaltborne both make that separation structural.
Observability
Tool calls, retries, confidence, approvals, and stop reasons have to be reconstructable later.
Where learned: Adversarial testing asked whether each attempt was visible in the audit log.
Concepts exercised in this project
- Agent architecture
- State classification
- Tool selection
- Safe stopping
- Human approval
Security principles applied
Least privilege
Separate collection, analysis, and remediation. Give the current task only what it needs.
Where learned: Triage agent; publishing-agent allowlist; Clearward directory and spending boundaries.
Logging and accountability
Decisions, tool calls, retries, and approvals have to be reconstructable.
Where learned: Triage adversarial study scored whether attempts appeared in the audit log.
Validation
Schema, hashes, required fields, RLS tests, and visual review — not the generator marking its own homework.
Where learned: Clearward formula/package QA; Basaltborne Zod + pgTAP; TinyClaw source checks.
Controls exercised in this project
- Least privilege
- Prompt-injection resistance
- Audit logging
- Change control
Technologies
- Agent state model
- Tool allowlists
- Deterministic validators
- Audit logging
Skills demonstrated
- Agent Architecture
- State Classification
- Tool Selection & Allowlists
- Deterministic Validation
- Prompt-Injection Resistance
- Least Privilege
- Retry Limits & Safe Stopping
- Human Approval Gates
- Audit Logging