Agents for Humans: We Built an Agent That Does the Boring Part of Interactive Fiction
We built ST-Agent to turn plain-English story ideas into validated, SillyTavern-ready character cards and lorebooks. Here’s how we used the Strands Agents SDK, bounded tools, local file state, and a code-enforced delivery gate to keep the model flexible without letting it fake “done.”
Series: Agents for Humans: Building ST-Agent (3 articles)
- 1Agents for Humans: We Built an Agent That Does the Boring Part of Interactive Fiction This article
Every hobby has a part that sucks the fun out of it. For people who write interactive fiction and play their own stories in SillyTavern, it's not the writing. It's the packaging. A character card is a pile of JSON fields, a lorebook with keyword triggers and injection positions, maybe a PNG with the whole card stuffed into metadata chunks. Get one field wrong and your character loads half-broken, or worse, loads fine and plays nothing like you imagined.
We kept running into the same mismatch: the fun part was inventing a character and a world; the slow part was turning that idea into files SillyTavern could actually use. When the Agents for Humans hackathon came around, the project was an obvious fit — let the agent handle the repeatable work, and let the human keep the creative decisions.
What we built
ST-Agent is a local Windows app. You pick a workspace folder, describe your story idea in plain English, optionally upload source files — drafts, existing cards, lorebook JSON, a portrait image — and chat with a single agent until your character package is done. It asks a clarifying question when something actually matters (JSON or PNG? lorebook standalone or embedded?), waits for an explicit "yes" before it builds anything, then produces validated, SillyTavern-ready files in your folder.
Under the hood it's the AWS Strands Agents SDK doing the reasoning, a thin Streamlit page for the UI, and an OpenAI-compatible model endpoint you configure in the sidebar. There are no user accounts or hosted project storage. Case files stay in the local folder you selected.
The decision that shaped everything
The tempting design was a fixed wizard: collect a few fields, run a pipeline, and emit some JSON. That would have been easy to explain and frustrating to use. Creative input does not arrive in a fixed shape. One creator starts with three pages of worldbuilding; another starts with one sentence and needs the right question before anything useful can happen.
The opposite extreme — letting a model improvise the entire workflow — was not acceptable either. The application writes files into a real workspace, and the difference between “done” and “looks done in chat” matters. We ended up with a hybrid and one rule that shaped the rest of the system:
The model can decide what to do. The code decides what's true.
Concretely: the agent reasons, asks questions, and picks among eight narrow tools —
save_brief, save_content_document, build_character_card, build_lorebook, build_png_card, check_official_sources, validate_deliverables, and finish_case. Each has one job and a structured return. Every file write goes through deterministic services, and delivery is gated: a confident chat response cannot create a download. The UI exposes only artifacts that exist in the case folder and passed the required checks.That one rule drove most of the architecture. Case state lives in a plain
case.json in your workspace, written atomically, so an interrupted build can resume from what actually reached disk. Uploads are identified from bytes, not trusted by extension, and checked before they enter the workspace. The agent gets no shell, no arbitrary filesystem access, and no open-ended network tool.Things we'd do the same way again
- Use Strands for decisions that are genuinely dynamic. Question timing and tool order depend on the creator's material, so the model-driven loop earns its keep.
- Files as the source of truth. No database, no hidden session state. Everything the agent knows about your case is in your folder, human-readable. When something went wrong during development, we could just... look at the files.
- One process. Streamlit owns the UI and the agent. Boring, debuggable, and fast to ship.
Where it stands
The release candidate is public under MIT, with more than 200 automated tests, Windows CI, a locked dependency set, and a full architecture write-up at github.com/Lockyer228/ST-Agent . Over the next two posts in this Agents for Humans series, we'll go deep on the delivery-gate pattern — why we think every agent that produces files should have one — and the lessons Strands taught us about bounding an agent's authority without clipping its usefulness.
If you're building something for this hackathon too, the cheapest advice we can give: decide early what your agent may decide versus what your code must prove. Everything else follows from that line.
Series: Agents for Humans: Building ST-Agent (3 articles)
- 1Agents for Humans: We Built an Agent That Does the Boring Part of Interactive Fiction This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article