Engineering Notes · Internal Systems

Digiton Runs on Digiton: Inside Our Local Agent Fleet

Before I sell a client on running their operations through AI agents, I run mine that way first. Here is the pattern behind Digiton's own agent fleet.

By Brandon Da Costa, Founder, Digiton Dynamics

Eating your own cooking, literally

I do not think a consultancy should sell AI operations to clients without running its own operations the same way. Digiton's internal agent fleet, part of what I call AIOS CC, handles a real slice of the company's own sales and operations work: monitoring, classification, drafting, follow-ups. It is not a showcase built for a sales deck. It runs every day whether or not anyone is watching.

Why local scheduling instead of a workflow SaaS tool

A lot of automation tooling defaults to a hosted workflow platform: drag-and-drop nodes, a vendor dashboard, a monthly bill that scales with volume. For Digiton's own operations I chose a different pattern: agents scheduled locally with launchd, the native macOS scheduler, running on a fixed cadence rather than living inside someone else's platform. That decision was not about avoiding all third-party tools, it was about keeping the operational core simple, inspectable and cheap to run at the volume a small, real business actually generates.

What the pattern actually looks like

Each job is a small, focused script with one job: watch an inbox for a specific signal, sync a pipeline stage, draft a follow-up, classify an inbound message. Every job logs what it did, keeps its own state on disk so it can pick up where it left off, and reads from a shared configuration rather than duplicating constants across scripts. None of this is exotic engineering. What makes it work is discipline: small files, one responsibility each, and state you can actually inspect when something looks wrong.

The kill switch is not optional

Every agent in the fleet respects a single kill switch: a file that, if present, stops every job from taking any action, immediately. I built that in from day one, not after something went wrong. Any system that acts autonomously on your behalf, especially anything that touches outbound communication, needs an instant, unambiguous way to stop everything, and it needs to be simpler than debugging the system itself under pressure.

What almost went wrong early on

The first version of the fleet did not have the kill switch, because in the earliest days it was one script doing one small job, and stopping it meant closing a terminal window. That stopped being true almost immediately, and I built the kill switch in before I let a second agent start touching anything client-facing, specifically because I could picture the failure mode: an agent misclassifying something and taking an action nobody asked for, with no fast way to stop the rest of the fleet while I figured out what happened. Building the safety mechanism before scaling the fleet, rather than after an incident, is the one process decision from this project I would defend without hesitation.

How I decide what belongs in the fleet

Not everything I could automate belongs in the local agent fleet. The tasks that fit are recurring, well-defined, and low-ambiguity: watching for a specific signal, drafting something a person will review before it goes out, syncing state between two systems that should already agree. Anything that requires genuine judgment on a case that has never come up before stays with a person, at least until I have watched the fleet handle enough similar cases to trust the pattern. That filter is intentionally conservative, and it is why the fleet has grown slowly rather than all at once.

Cost and control, not just automation

Running the fleet locally, scheduled rather than reactive, on a fixed cadence, also keeps cost predictable in a way that a metered API call per event does not. I know roughly what the fleet costs to run in a given week, because the schedule is fixed and the jobs are bounded, rather than discovering the bill after usage spikes. That predictability is part of why I trust the pattern enough to recommend it to clients who are nervous about handing operational tasks to AI agents in the first place.

Why this matters if you are evaluating an AI agency

Ask any AI consultant or agency one honest question: does your own business run on the thing you are selling me? For Digiton, the answer is yes, and the agent fleet is the proof, not a claim. If you want to see what a similarly disciplined system would look like inside your own operations, that is exactly the kind of build I do through Digiton's AI agency work. Get in touch and I will show you honestly what would and would not make sense for your business.

Frequently asked questions

Related