When I first started using Claude to help prepare our church's daily spiritual messages, I was not trying to build an AI agent. I simply wanted to reduce the repetitive work involved in preparing six Chinese messages for publication in English.
But after several iterations, I realized that I was gradually designing something that looked much more like an agentic workflow: an LLM handled language and reasoning tasks, Python handled deterministic file transformations, and a human remained responsible for review and final publication. The surprising lesson was that full automation was not necessarily the goal.
The more I worked on the workflow, the more I realized that a useful AI agent may be a hybrid system rather than a completely autonomous one.
The Real-World Problem
The weekly workflow starts with six Chinese daily spiritual messages, typically Monday through Saturday, provided as PowerPoint and PDF files. The goal is to produce a bilingual publication and an English version for our church website.
The simplified workflow is:
At first glance, this looks like a straightforward translation problem. Actually it is not. The source document contains dates, day labels, spiritual headings, Bible references, Bible quotations, section headings, daily prayer and hymns. Different elements require different treatment.
For example, Bible quotations should use NASB 2020 rather than being translated directly from the Chinese message. Hymns should remain untranslated. Subheadings need specific formatting, while daily prayer needs to preserve its structure.
The first LLM prompt therefore became much more than a translation request.
Step 1: Turning Translation into a Structured Skill
My initial Claude Project instruction was simple:
Translate six Chinese messages into English while preserving the Chinese paragraph structure.
But the prompt quickly evolved into a detailed specification. It instructed Claude to:
- Reference Living Stream Ministry's Life Study material for terminology and context;
- Translate Scripture references but not translate the Bible verses under the title;
- Use NASB 2020 for quoted Bible verses in the message;
- Translate key points and daily prayer;
- Leave hymns untranslated;
- Preserve subheadings using bold Markdown;
- Preserve Daily Question formatting;
- Produce one JSON object for each day; and
- Output only
titleandcontentfields.
The resulting JSON has a predictable structure:
{
"Monday": {
"title": "Isaac's Experience — Receiving Grace (1) — Eph. 1:2",
"content": "..."
},
"Tuesday": {
"title": "Isaac's Experience — Receiving Grace (2) — Eph. 1:3",
"content": "..."
}
}
The LLM was no longer simply generating prose. It was producing output according to an interface contract. That distinction became critical because the next step was performed by software.
Step 2: From LLM Output to Deterministic Software
Once the JSON is generated, I use Python to insert the English content into an English PowerPoint template. This is where I discovered an important principle:
Not everything should be done by the LLM.
Generating the English translation requires language understanding and contextual judgment. Putting a string into a particular PowerPoint text box is deterministic. There is no reason to ask an LLM to perform that job.
The Python program knows the mapping:
Monday → Slide 1
Tuesday → Slide 2
Wednesday → Slide 3
...
It inserts the corresponding title and content, generates the PowerPoint and saves the file. However, the resulting presentation still requires human review. The reason is PowerPoint formatting is visual.
The text may technically fit inside a text box but still look wrong. A paragraph may create an undesirable page break. A font may need adjustment. A title may wrap differently from the original. The computer can determine whether the text was inserted, while a human can determine whether the slide looks right.
That's the boundary between deterministic automation and human judgment.
Step 3: Document Transformation as Another Skill
After the English PowerPoint is reviewed, another automation step merges it with the Chinese PowerPoint. The final presentation contains twelve messages: six Chinese and six English, aligned by date.
Again, this task does not require an LLM. There is no reason for an AI model to decide:
Which Chinese slide corresponds to April 28, 2026?
The date provides the answer. This led me to think about the workflow as a collection of different types of skills or capabilities.
LLM skills — reasoning
- Translation
- Scripture and contextual interpretation
- Terminology selection
- Content structuring
- Semantic formatting
Software skills — deterministic
- JSON parsing
- PowerPoint generation
- Date matching
- Slide merging
- HTML generation
Human skills — judgment
- Translation and theological review
- Visual quality control
- Final publishing approval
The "agent" is therefore not a single model — it is an orchestration of different capabilities.
Step 4: From PowerPoint to HTML
The final transformation converts the English PowerPoint into HTML that can be pasted into a WordPress post. Again, this initially sounds like something an LLM could simply "do." But there is an important distinction between understanding content and performing a deterministic transformation.
The conversion needs to preserve:
- paragraphs;
- titles;
- bold text;
- italic text;
- Monday-through-Saturday ordering; and
- the English title at the beginning of each message.
Not every paragraph has its own title. The entire daily message, however, has an English title. The program can deterministically extract the PowerPoint text and produce the basic HTML structure. An LLM can assist when semantic interpretation is required, while a human can inspect the final result before publication.
The AI/Orchestrator View
At this point, I stopped thinking about the project as a sequence of automation scripts and started thinking about it as an orchestrated system.
Figure 1. A hybrid agentic workflow combining LLM reasoning, deterministic software capabilities and human judgment.
The orchestrator's role is not necessarily to perform every task itself.
Instead, it can:
- Understand the overall goal and constraints;
- Decompose the workflow;
- Route each task to the appropriate capability;
- Monitor intermediate outputs;
- Validate whether an output is ready for the next step; and
- Stop and escalate to a human when judgment is required.
Controlled autonomy means the system automates what is predictable and pauses where judgment matters.
Why Didn't I Fully Automate It?
At the beginning, I thought:
"If Claude can translate the content, why can't I build an agent that does the entire workflow?"
Technically, many individual steps can be automated. The problem is reliability across the entire chain:
- A translation can be grammatically correct but contextually inappropriate;
- A Bible quotation can be almost correct but fail to match the required version exactly;
- A JSON response can contain an unexpected formatting issue;
- A PowerPoint can be structurally correct but visually unattractive;
- An HTML document can be syntactically valid but render incorrectly in WordPress;
- Publishing has a different standard from a casual chatbot conversation.
When the output goes directly to a public website, "mostly correct" is not always good enough.
An autonomous agent is often described as a system that independently completes a task from beginning to end. But in real-world applications, maximum autonomy is not always the best architecture.
Sometimes the smarter design is knowing when to stop.
What I Learned About Building Agents
1. Start with the workflow, not the agent
Don't begin with:
"How can I build an AI agent?"
Begin with:
"What is the actual workflow, and which parts require intelligence?"
Once the workflow is decomposed, it becomes much easier to decide where an LLM belongs.
2. Separate reasoning from deterministic processing
If a task has a predictable input and output, traditional software is often the better tool. If a task requires interpreting language, context, ambiguity or meaning, an LLM becomes much more valuable. This sounds obvious, but mixing these responsibilities can make an agent unnecessarily complicated and less reliable.
3. Treat prompts as interfaces
A production prompt is not simply an instruction to an LLM. It can define an interface between the model and the rest of the system.
My JSON requirements are a simple example. The LLM produces structured output that Python can consume. That interface becomes the boundary:
LLM reasoning → structured interface → deterministic software
The more clearly that interface is defined, the easier it becomes to test and automate the downstream workflow.
4. Human-in-the-loop is a feature
I initially viewed human review as something I would eliminate once the system became more mature, but I no longer see it that way.
For content requiring contextual, theological, visual or publishing judgment, human review provides an important quality and accountability layer. The goal is not to make humans disappear, but to make their involvement more focused and valuable.
5. The best agent may be hybrid
The final system is neither "AI" nor "traditional automation."
It is a combination:
LLM + deterministic code + human judgment
The LLM handles what machines traditionally struggle with: language and meaning. Code handles what LLMs should not be trusted to do: predictable transformations. Humans handle what still requires judgment and accountability.
Conclusion
What started as an attempt to save time translating six weekly church messages became an unexpected experiment in agent design. I did not end up with a completely autonomous agent. Instead, I ended up with something that may be more useful: a hybrid AI workflow in which each capability has a clearly defined role.
The biggest lesson was simple:
The goal of an AI agent should not always be to remove humans from the loop. The goal should be to remove unnecessary human effort while preserving human judgment where it matters.
For real-world AI systems, that distinction may be more important than how autonomous the agent appears. Sometimes the smartest agent is the one that knows what it can automate, what it should delegate to software, and when it should stop and ask a human to take over.
Top comments (0)