How to Build an Orchestra: A Systems Design Approach to AI Workflows

I do the product management, design, and development for a publishing platform. Designing and building it has become something else entirely. It’s now a working model for how small organizations can use automation, AI, and agentic workflows, in concert with people, to do things that should, by any reasonable accounting of their resources, be impossible.

That’s the framework I want to offer here. Not “we implemented AI”, but the more useful question every new technology forces us to ask instead, “how does this help us become ‘more ourselves’?” For an independent publisher, that means protecting editorial judgment while eliminating everything that always gets in its way, things like routine drudgery, bottlenecks, and the tasks that pile up because no one can or wants to do them. These affect small businesses the most because they don’t have the operational flexibility to hire someone to handle them.

I’ve been reading a lot lately about large organizations laying off thousands of people because AI can replace what they do. That may be true. But it’s the wrong conversation for most of the world’s businesses. Large organizations have a resource-optimization problem. They have people and want fewer of them. Small organizations have a resource-existence problem. They don’t have people and can’t afford them. The question for smaller organizations isn’t how to replace human labor, it’s how to do work that otherwise simply wouldn’t get done. This is where AI is genuinely transformative. It’s not as a cost-cutting measure for billion-dollar companies, but as a force multiplier for businesses and creators who couldn’t afford to be in the game at all.

Four Workflow Pillars

The publication platform I’ve been building has given me a concrete, multi-year space for working this out in practice. The publishing workflow breaks out into four stages: submission intake, editorial approval, publication and asset creation, and distribution. 

Each stage raised different questions about where AI, agents, and automation could help, where human judgment is non-negotiable, and, critically, where the cost of an AI error is acceptable versus where it’s catastrophic. That last question doesn’t get asked enough. It should be the first one.

In the model I built, these four pillars use automation, agents, and human-in-the-loop, all working together at different stages in the process. This workflow demonstrates the power of and necessity of a deliberative, systems design approach in creating AI workflows. It isn’t enough to “integrate AI’ or “give an agent your intent and let it loose”. This is more like an orchestra, with different instruments playing different roles, but all necessary for producing a coherent symphony.

Entry Submission Workflow

Publishing platforms face a data-intake problem familiar to anyone who has worked with CRM or ATS systems. Author biographical information has to be collected, stored, matched against existing records, and reformatted to the publisher’s style. The submitted work itself must be captured cleanly and routed into the review process. These sound like solvable problems. They are, but not always in the way you would expect.

Many publishing platforms accept Word document submissions. We used to as well. The problems this creates are practical and compounding: you can’t charge per individual submission, you can’t track submissions through an approval workflow, and you can’t reliably transfer content from a Word document to a publishing platform while preserving formatting. That last point matters more for poetry than almost anything else. Line breaks aren’t decoration. They are integral to meaning.

The obvious AI solution presents itself immediately. Why not let authors submit Word documents, have an LLM parse the title and content, preserve the formatting, and route the result into the workflow? That solution would be clean, invisible, and convenient for the author. This is exactly the kind of reasoning that tends to go unexamined in discussions of agentic design.

But what is the cost of an error, and who bears it? 

A corporation running an ATS can accept a meaningful false-negative rate. A qualified candidate gets dropped; the organization has decided it can absorb that cost. The candidate bears it, not the company. 

Our situation is structurally different. If an AI parsing a Word document decides that a poet’s two separate poems are actually one, or reads an intentional line break as formatting noise, the consequences aren’t just technical. We have an author whose work has been misrepresented, an incorrect record, and no efficient way to fix it in an organization with no capacity to constantly check and resolve preventable errors. There’s also a relational cost. We’ve damaged a contributor’s trust in us with our tooling.

The error-tolerance framework should precede every AI design decision. What is the acceptable error rate for this task? What is the cost of a mistake? Who absorbs that cost? Who shoulders the blame when things go wrong? When the answers are “near zero,” “significant,” and “the person we’re supposed to be serving”, those are all reasons to pull AI out of the loop entirely.

So in our publishing workflow, the burden falls on the author. They enter and format their work as they want it published. 

Authors don’t love this for the same reason job candidates don’t love entering their entire work history into an application form. They’re both approaching the process from a volume perspective, hoping to cast a wide net. Organizational philosophy also played a role in the decision to design it the way we did. We want authors who want to be published with us, not just anywhere. The friction is a filter. It’s doing useful work.

Approval Workflow

Just like logistics and ATS software, publishing platforms need to track an object through a workflow. We’re tracking submissions through a publication process. 

The approval workflow is entirely automated via email, and deliberately so. It follows the same pattern for every submission: submission received -> editor reads and accepts or rejects -> author agrees to publication -> piece is prepped for publication -> waits in the queue -> published. Authors expect email notifications about submission status; it’s a convention they’re accustomed to, much like job candidates expect application updates. Automation here is invisible and appropriate.

The more important point is what’s not automated. An agent does not approve or reject submissions. A human editor reads every piece and makes a judgment call. This isn’t a technical limitation. It would be straightforward to build a classifier that screens submissions against editorial criteria. It’s a principled decision, and it matters more than it might seem.

If an autonomous system makes editorial decisions, the journal ceases to be a journal. Editorial judgment is what defines the publication. It’s what differentiates this journal from others. It’s the thing readers trust, and authors seek out. Automate that, and you haven’t made the journal more efficient; you’ve made it something else entirely. This is the “more us” question applied directly. What is the irreducible core of what we do, and what would its automation destroy?

This is the broader point I want to make about the automation-versus-agent discussion. Not everything benefits from being handed to an autonomous system. We need much more structural clarity, in practice, not in theory, on what it actually means for an autonomous system to plan, decide, and execute complex workflows without human oversight. How much of that is viable in a real business without breaking something important? In my experience building this out over several years, it is less than what is currently being promised, and the breakage tends to be the parts of the business that are hardest to recover.

Publication and Asset Creation Workflow

This is the stage where I’ve used AI, agents, and automation heavily, and for straightforward reasons. The work here is dull, repetitive, and genuinely unengaging: creating WordPress posts, setting up author profiles, resizing avatar images, and generating visual assets. 

Nobody at the journal wants to do this work. There isn’t the budget to hire someone to do it. A job isn’t being eliminated because the job never existed to be eliminated. AI and automation are making work that otherwise simply wouldn’t happen possible. Or, let me put it this way, we would publish fewer pieces and less frequently.

Once the approval workflow completes, three things happen in parallel: a draft post is created with the author’s formatted text, an author profile is created, and an image is generated for the piece. Agents handle the parts that require judgment within constraints, and automation handles purely mechanical tasks.

Author Biographies and Avatars

Author bios sometimes require light editorial intervention. They don’t always require editing, but they always require review.

We ask for third-person voice and a specific formatting style for publication names. Publication titles require italics, capitalization rules vary, and “The” is sometimes part of the masthead. Author compliance is imperfect, and even editors frequently have to look up publication names.

An agent handles the review, rewrite, and formatting. It reads the submitted bio, corrects the point of view, and applies publication name formatting. It performs at roughly editorial quality most of the time. That’s a good enough benchmark for us. We don’t need perfection, just comparable to what a careful human editor could do.

Avatar images present a standard interaction design problem. We could specify upload dimensions and ask authors to crop and resize their own images. If you’ve looked at LinkedIn profile headers, you already know how this plays out. People lack the tools, skills, or motivation to achieve good results, even with instructions, and adding technical requirements at submission creates friction and abandonment. So we don’t. 

Authors upload whatever they have, and automation handles face detection, cropping, and resizing. Google Vision deals with face detection. It looks at the image, finds the face, adds padding and sends the coordinates to WordPress. Then sends them through the WordPress image editor framework to crop and resize according to the coordinates it receives and the target dimensions.

But sometimes, we get artwork or a cat. Those produce variable results. If Google Vision doesn’t find a face, it returns nothing, and WordPress uses its default crop. This is exactly why humans review all automation and agent output before anything goes live. The agent reduces the work; the editor retains the judgment.

Artwork and Image Generation

Every piece we publish is paired with a custom image. We moved away from stock photography after a redesign for both aesthetic and practical reasons. Stock imagery reads as stock. Readers recognize it immediately, and it flattens the reading experience rather than enhancing it. A custom image created specifically for a piece accompanies the work rather than illustrating it in a generic way. It also solves a downstream problem. A published image is available for social media reuse.

This has had the most operational impact on the poetry category. We publish a high volume of it, which means steady demand for images. This is an area well-suited to AI generation with human oversight.

An agent scans a folder containing a structured text file of poems, selects from seventeen image templates and chooses a lines from the poem to overlay on the image. The agent is instructed to select lines from the poem that are both visually evocative and legible outside the poem’s original context. It overlays the text onto the template it chose and outputs a JPEG to a review folder. We can either use the image or make something else ourselves.

There are a few decisions here that are worth pointing out. 

I use a structured text file rather than giving the agent access to WordPress drafts, because that would require giving it credentials. Since I can’t run this natively inside WordPress, this is how I chose to design and operate it, on the outside.

This is a principle I’ve applied across every AI workflow I’ve built. I don’t give autonomous systems access to anything where a mistake is catastrophic or unrecoverable. The agent doesn’t need CMS access in this instance to do its job. It needs a text folder and a template folder. Constrained access isn’t a limitation; it’s architecture. It’s the same principle as least-privilege access in security design, applied to AI systems before things go wrong rather than after. 

The instruction to select “visually evocative” lines that can also stand alone outside the poem’s context encodes something I struggle with myself when creating these images. A line can be emotionally arresting within a poem and opaque without it. The agent navigates this with reasonable success, most of the time. When it doesn’t, an editor makes a different image.

AI doesn’t replace custom image creation for prose pieces. We usually don’t have one or two compelling lines that work outside the context of the story we can overlay on a generic template.

AI-generated imagery works as a starting point, but the path from start to publication-ready involves significant human editing that I haven’t found a way to shorten. Not every workflow problem has a current AI solution, and a good systems framework requires understanding its limitations.

Distribution Workflow

This part of the system is the most straightforward. Once a piece is published, we send it out on social media. Again, it is a necessary part of the job, but not something anyone is highly motivated to do.

The social media agent is part of the publishing workflow. It scans the site for newly published pieces once a week, grabs the featured image from the WordPress post (this was what I referred to earlier when I talked about leveraging assets from the Image Creation Agent), writes a summary based on the text of the piece, and publishes it to a page for us to review before publishing to social media. It keeps a log of entries it has created, so it doesn’t re-create posts when it does a scan. The entire archive isn’t scanned, only the last 25 entries. We never have a backlog of published pieces without promotion larger than that, so setting the limit avoids scanning the entire archive every time. 

Social media posting is expected of us, like most entities, but in reality, it doesn’t drive the most traffic or readership. We do it because it drives traffic when authors who are active on social media share our posts about their work. While most of our authors are active on social media, like most people, they generally don’t have large followings. However, we certainly see an impact from those with larger, more active networks.

This is probably where we are most hands-off in the process, and where the use case for an agentic tool makes the most sense. It is a low-stakes, low-risk part of our workflow. There aren’t a lot of eyeballs on these channels on our social media, so it doesn’t matter much if the occasional awkward post gets through. This content isn’t as highly valued as contributor poetry, short stories, or essays are. We will get polite emails if something is incorrect in an essay we’ve published, but it is unlikely we’ll be contacted if a social media post about the same essay contains incorrect information. It’s ephemeral, so we can afford to allow an agent more autonomy over the process. 

Low-risk, high-reward scenarios are appropriate for automation. It’s low risk because the occasional weird post doesn’t have a big impact on our workflow, revenue, or staff. We review before publication. If it is really out of compliance, someone has to make one from scratch for that piece. It doesn’t happen very often. It’s high-reward because it is a task that was previously delayed, ignored, or dreaded, but is now handled by an agent. It’s something we must do, but the human drudgery is removed from the process.

Conclusion

This is a systems approach to thinking about AI, agents, and humans as a team working together to solve the fundamental problem many small businesses and organizations face: how to grow without the revenue or staff of a large company.

From this thinking, a framework emerged. The essentials of the framework can be reduced to a handful of questions to ask when considering AI integrations, such as: what error rate is acceptable, who bears the cost when something goes wrong, and what is the irreducible core of this work that automation would destroy rather than support? How do we design a system that leverages AI, agents, automation, and humans to help small businesses and organizations be “more themselves”?

Discover more from MISTY CRIPPS | VAQUITA DESIGN

Subscribe now to keep reading and get access to the full archive.

Continue reading