<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Architecture on Acestus // Cloud &amp; AI Engineering</title><link>https://blog.acestus.com/tags/architecture/</link><description>Recent content in Architecture on Acestus // Cloud &amp; AI Engineering</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 11 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.acestus.com/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Purpose-Built AI: A Field Toolkit for Engineering Operations</title><link>https://blog.acestus.com/posts/purpose-built-ai-a-field-toolkit-for-engineering-operations/</link><pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate><guid>https://blog.acestus.com/posts/purpose-built-ai-a-field-toolkit-for-engineering-operations/</guid><description>General-purpose AI assistants have an infinite goal space and no defensible perimeter. The fix: build AI that does one thing, for one domain, with a defined scope.</description><content:encoded><![CDATA[<p>General-purpose AI assistants have an infinite goal space. Give one the instruction &ldquo;answer whatever the user asks&rdquo; and you&rsquo;ve created a system with no defensible perimeter — every question is a new attack surface, every novel request a potential failure mode. You can&rsquo;t patch your way to safety when the boundary is everywhere.</p>
<p>The fix is simple to describe: build AI that does one thing, for one domain, with a defined scope.</p>
<p>This is a field implementation of that idea.</p>
<hr>
<p><strong>The Substrate</strong></p>
<p>The toolkit lives in a git repository. Every Jira ticket and SDP case has a markdown file. Every action — worklog, comment, investigation finding, stakeholder nudge — is written to that file before anything touches an external system. CI/CD syncs the file state on push. The markdown is the source of truth. Jira and SDP are render targets.</p>
<p>Every AI action is reversible, visible, and auditable. There&rsquo;s no hidden state evaporating when you close a tab. The human approves the file; the system transmits it. That sequence is the crumple zone.</p>
<hr>
<p><strong>A Dispatch Table, Not a Chatbot</strong></p>
<p>The toolkit is a set of narrow skills, each with a defined scope:</p>
<ul>
<li><strong>Clerk</strong> — institutional memory retrieval. Searches issue files, case files, Confluence, and reference repos. Cites sources. Never synthesizes. If it finds nothing, it says so: this is new ground.</li>
<li><strong>Rounds</strong> — kanban station management. Claims one lane, works one ticket, manages all paperwork without touching anything outside that ticket&rsquo;s scope.</li>
<li><strong>Ticket Investigator</strong> — structured problem decomposition. Runs a six-dimension confidence interview. Won&rsquo;t proceed below 95%.</li>
<li><strong>Confluence Writer</strong> — documentation only. Drafts to file, publishes on operator approval.</li>
</ul>
<p>Eleven dispatch situations. Eleven named skills. No open-ended improvisation.</p>
<hr>
<p><strong>Calibrated Autonomy</strong></p>
<p>Every ticket carries an agentic score (1–5) set at intake — a pre-classification of how much human involvement the work requires. Score-1 tickets run to completion without human checkpoints. Score-5 tickets are context-only: the AI reads, summarizes, and steps back. A constraint:technician label caps autonomy regardless of score.</p>
]]></content:encoded></item></channel></rss>