An agent task often goes wrong before the first line is written. “Prepare the launch” could mean drafting copy, editing a landing page, generating a video or scheduling a post. Sometimes the agent seems to choose whichever sounds most entertaining.
I am trying to make tasks smaller. The result should have a boundary and a way to check it. For content about my projects, that means separating writing, automated checks and the decision to publish.
A real example: checking a draft's voice
My content repo has a voice and safety linter. It is a Python script that reads a draft and applies rules from a separate lexicon file.
It checks things I can define reasonably precisely: names that should not appear, expressions I avoid and certain writing patterns. It returns findings and distinguishes blocking errors from warnings that need review.
That is useful work to automate. An agent should not need to reinterpret a concrete prohibition every time it writes a paragraph. I can make that prohibition a repeatable check.
The linter was added on October 12. Evaluation cases sit alongside it to check that it rejects previously discarded examples and allows an accepted one. When the filter changes, those cases help check the filter itself.
What the linter cannot tell me
A piece can pass every rule and still be a bad piece of writing.
It might explain nothing, choose an uninteresting angle or describe a tool's documented capabilities as if they were my personal experience. A list of forbidden words will not catch all of that.
It also cannot establish whether a number is true. Describing an existing feature requires checking the project. Claiming time savings requires measuring them.
So “linter passed” does not mean “ready to publish.” It is one check with a particular scope.
A task with explicit boundaries
A useful review request might look like this:
Read the voice guidelines and this draft. Flag claims that need sources. Check the project's current README to verify the features mentioned. Propose changes only in this file. Do not generate media, commit or publish.
I can then request corrections to the identified problems. The first pass already has a reviewable output: what is wrong, where it is and which evidence supports that finding.
If the agent cannot verify a claim, I want it to say so. A visible pending item is easier to deal with than a gap disguised as a convincing sentence.
Permissions I keep separate
In this workflow, preparing, modifying and publishing are separate permissions. Reading a guide to propose a draft does not require authorization to push changes. Editing that draft does not imply permission to schedule it on a social platform.
This will not prevent every possible mistake. It limits the consequences of a misunderstood task.
I also try to separate the writing and review passes. Writing aims to explain an idea clearly. Reviewing returns to the sources and tries to find what does not hold up. Doing both at once makes it easy to accept a paragraph simply because it sounds good.
Task size matters
Not every request needs elaborate orchestration. Fixing a sentence is a better fit for a direct task than a discussion about agent architecture.
But a job involving copy, visuals and publication needs review points between steps. Each output brings new decisions about what to show, what to promise and what to leave out.
I have written about testing and code review with agents. Content has a similar boundary: I can delegate a specific check. Accepting the whole result because the agent says it has finished is a different decision.