AI Agents
Patch Agent: how I built an AI ops agent for my software company
I run SquareWave Studio. We make desktop software for Teenage Engineering devices. EP-PatchStudio is our main product: a cross-platform Tauri/Rust app that creates multisamples and manages EP-40, EP-133 and EP-1320 hardware.
As a solo founder shipping across Windows, Mac and Linux, I knew the operational overhead would catch up with me. Support emails. Discord community monitoring. Bug triage. Revenue tracking. Content creation. Campaign management. Analytics across three websites and a desktop app.
I needed to either hire people or build something. I built something.
What Patch is
The first version took 3 hours. A support triage bot that checked email and created GitHub issues. It worked well enough that I kept building.
Over the next few weeks I spent another 6 hours turning it into something that runs my entire operation. Its name is Patch. It is the SquareWave Studio Ops Agent.
Two TypeScript services: a scheduler/agent runtime (the Service) and a web dashboard (TS + React). The Service runs three automated cycles and connects to everything my business touches through MCP integrations and direct APIs.
Built with Claude Code. Runs on the Claude Agent SDK.
Patch is not a chatbot. It is a persistent agent with a scheduler, a knowledge base, a memory system and governance around every tool call.
The three cycles
Every 2 hours: support triage
Patch checks the Zoho Mail inbox (MCP, read-only) and the Discord community server. When it finds a bug report it does the following:
- Checks for duplicate or related open issues on GitHub
- If a match exists it links the new report to the existing issue and notifies me if the severity has changed
- If it is new it creates a GitHub issue with the user’s description, reproduction steps (if provided) and its own initial analysis
This is where the dev pipeline takes over. GitHub Actions hands the issue to the SquareWave Dev Agent (Claude Code) which reads the issue, investigates the codebase, attempts a fix and raises a PR. If it cannot fix the issue it documents what it found and flags me.
I get a Pushover notification either way. The notification deeplinks to the dashboard where I can see the full agent conversation, the code changes and approve or reject the PR.
Urgent problems (a Pro customer unable to use the app, for example) trigger an immediate Pushover alert so I can respond directly.
Every 6 hours: brand monitoring
Patch searches Reddit, music production forums (Elektronauts in particular) and Google for mentions of SquareWave Studio, EP-PatchStudio, OP-PatchStudio and related terms.
It collects mentions into a database with metadata: source, sentiment, whether it references a bug or feature request, whether it needs a response. Anything that looks like a user reporting a problem with my software triggers an immediate notification.
This cycle also gathers collateral intelligence. Competitor mentions. Adjacent product launches. Community sentiment about Teenage Engineering’s own tools. All of this feeds into the daily digest and the knowledge base.
Every 24 hours: daily digest
A single Pushover notification with the previous 24 hours in summary:
- Sales figures from LemonSqueezy (revenue, refunds, conversion rates, anomalies)
- Open issues and PRs across all repositories
- Community mentions and overall sentiment
- Campaign performance from Brevo
- App analytics from PostHog (DAU, geographic distribution, error rates, abandoned carts)
The notification links to the dashboard where every number is backed by a full report and the ability to drill into the agent conversations that produced it.
Architecture
The Service (TypeScript)
The core runtime. Handles scheduling, agent execution and tool orchestration. Built on the Claude Agent SDK which gives Patch persistent conversation context and tool use capabilities.
The Dashboard (TypeScript + React)
A web interface for everything Patch produces. BI dashboards with business metrics. Agent conversation deeplinks so I can see exactly what Patch was thinking when it made a decision. Reports on sales, analytics, community sentiment and campaign performance.
MCP integrations
Three services connect through MCP (Model Context Protocol):
Zoho Mail (read-only): Patch reads the support inbox but cannot send emails. Triage only.
PostHog: Analytics across three websites (ep-patch.studio, op-patch.studio, squarewave.studio) and the EP-PatchStudio desktop app. Error triage, user analytics, conversion tracking.
Brevo: Email campaign management. Patch can draft campaigns based on analytics and past performance data. Human approval is required before anything sends. It also reads campaign performance to inform the daily digest and content strategy.
Other integrations
LemonSqueezy: Revenue, refund tracking, conversion analytics. Patch flags anomalies like sudden refund spikes or conversion drops.
Discord: Monitors the community server for bug reports, feature requests and general user sentiment.
GitHub: Creates issues from triaged bugs. GitHub Actions pipelines trigger the SquareWave Dev Agent and SquareWave AgentDev Agent.
Data layer
SQLite: Operational database for structured data. Mentions, triage history, analytics snapshots, agent task logs.
LanceDB: Vector embedding database. Powers semantic search across the knowledge base and agent memory.
Memory system: When Patch encounters a problem and finds a solution it logs the resolution to its memory. Next time it sees a similar pattern it draws on that experience. This is the self-improvement loop.
Knowledge base
Markdown files loaded into LanceDB as vector embeddings. The knowledge base covers:
- Teenage Engineering hardware specifications and protocols
- EP-PatchStudio and OP-PatchStudio product documentation
- The music software and hardware landscape (competitors, adjacent tools, community preferences)
- Ideal customer profiles
- Marketing and sales tactics
- Launch strategy and positioning
This gives Patch the domain expertise to make informed decisions about triage severity, content drafting and campaign strategy. It is not guessing. It knows the product and the market.
The dev pipeline
This is the part most people find surprising. Patch does not just triage bugs. It fixes them.
When Patch creates a GitHub issue from a user report, GitHub Actions hands it to one of two dedicated agents:
SquareWave Dev Agent: Investigates bug reports, reads the codebase, writes fixes and raises PRs. Runs as Claude Code in a GitHub Actions pipeline with structured prompts.
SquareWave AgentDev Agent: Maintains Patch itself. If Patch discovers a bug in its own software it raises an issue on its own repository and the same pipeline kicks in. The fix gets tested in a sandbox Patch instance before human approval, merge and automatic deployment to production.
These are two of the four AI agents running SquareWave Studio. Patch handles operations. The Dev Agent and AgentDev Agent handle code. Together with the SquareWave WebDev Agent (which maintains the marketing sites) they form the full team.
The Dev Agent and AgentDev Agent do not use the Claude Agent SDK. They are Claude Code running in CI. The Agent SDK handles the orchestration and business logic (Patch). Claude Code handles the mechanical coding work. Right tool for the job.
The self-improvement loop means Patch gets better over time. Solutions get logged to memory. Bugs in Patch’s own code get fixed through the same pipeline. The system maintains itself.
Governance and security
This is the part I care about most. An autonomous agent with access to email, GitHub, payment systems and marketing tools needs serious governance.
Patch is governed by Vectimus Cedar policies on every tool call. Vectimus is an open-source governance engine I built that sits between an AI agent and its tools. Every tool call passes through a Cedar policy evaluation before execution. If the action violates policy it gets blocked.
Patch was actually one of the reasons I built Vectimus. Two motivations. First, sometimes you need an agent to operate with more autonomy and Vectimus lets you do that with protection rather than hoping nothing goes wrong. Second, the other frameworks available for agentic AI security did not offer the level of tool-use protection I needed.
The full security stack
CI/CD security scanning: Gitleaks for secrets detection on every push and PR. CodeQL for static analysis with security-extended queries. Trivy for dependency and filesystem vulnerability scanning (HIGH and CRITICAL only). Semgrep for SAST with auto rulesets.
Input validation: Zod schemas for runtime validation on all structured data. Type-safe tool definitions with strict input/output contracts.
MCP tool security: SQL write whitelists (INSERT, UPDATE, REPLACE only; blocks DROP, DELETE, ALTER). GitHub repo whitelists with branch naming enforcement. Path traversal protection on all file and key operations. Audit logging on every tool call.
Agent governance: Each agent has an explicit allowed_tools list. HITL approval gates in GitHub Actions through environment protection rules. Patch is governed by Vectimus Cedar policies.
Observability: OpenTelemetry for distributed tracing and audit trails. Structured logging throughout.
Dependency management: Dependabot for weekly and monthly GitHub Actions dependency updates.
What still needs a human
Patch is not running the company. I am. Here is what Patch cannot do and what I have no intention of automating:
Product decisions: What features to build. What to prioritise. How to position the product. Patch can surface data to inform these decisions but the decisions are mine.
Customer conversations: Anything customer-facing that requires empathy, nuance or a judgment call. Patch triages and drafts. I review and send. Brevo campaigns require my explicit approval.
Code review: The SquareWave Dev Agent and AgentDev Agent write code and raise PRs. I review every line before it merges. The agents are good at routine fixes but they are not making architectural decisions.
Pricing and business strategy: Patch tracks revenue and flags anomalies. It does not set prices or change the business model.
Content with my voice: Patch drafts content based on brand guidelines and past performance. But the final version is always mine. Especially anything going on social media or to the mailing list.
The principle is straightforward. Automate the operational overhead. Keep the humans on product, customers and strategy.
Hosting
Patch runs on a Proxmox HA cluster hosted on Hetzner. The Service and Dashboard are both containerised. Nothing exotic. The infrastructure cost is negligible compared to the time it saves.
What I learned
Start with the triage cycle. The 2-hour support triage was the first thing I built and it delivered value immediately. If you are thinking about building something like this, start with the most repetitive operational task and automate just that. Expand from there.
MCP makes integration trivial. Connecting Patch to Zoho, PostHog and Brevo through MCP was remarkably straightforward. The protocol handles the complexity of tool discovery and execution. If your tools support MCP the integration work drops to nearly zero. MCP also offer many security benefits over pure CLI tools as you can scope the agent to only specific actions, for example Zoho email is read only, the agent can never send an email.
Governance is not optional. I built Vectimus because I needed it for Patch. An agent with access to your email, your payment system and your GitHub repos without governance is a liability. Cedar policies gave me deterministic, auditable control over what Patch can and cannot do.
The dev pipeline is the multiplier. The triage and monitoring cycles save time. The dev pipeline saves orders of magnitude more. Going from “user reports bug” to “PR ready for review” without human involvement in between is a fundamental shift in how a small team operates.
Memory and self-improvement matter. Early versions of Patch would hit the same problems repeatedly. The memory system changed that. Now when Patch solves something it remembers. The system gets better without me updating prompts or rules.
Build the dashboard early. I initially ran Patch headless with just Pushover notifications. Adding the dashboard with agent conversation deeplinks transformed my ability to trust the system. When I can see exactly what Patch was reasoning and why it made a decision, I can extend its autonomy with confidence.
The pattern scales
I am a solo founder. Patch handles operations for one company with a few products and a few thousand users.
The architecture is the same regardless of scale. A 50-person engineering team could deploy an ops agent per product, each with its own triage cycles, monitoring, dev pipeline and governance. The humans focus on product decisions and code review. The agents handle the operational overhead.
The question is not whether this pattern works. The question is how long before it becomes the default.
Patch runs on the Claude Agent SDK. Built with Claude Code. Governed by Vectimus. Learn more at squarewave.studio and vectimus.com.