Silas: a company that runs itself, on a short leash

How a business can be built as a colony of small, self-healing loops — the real mechanics, and the deliberate limits.

Most “AI for business” amounts to a chatbot bolted onto a workflow, or a drawer full of scripts that each do one useful thing until they quietly stop. Silas is an attempt at something harder: to run a company — and eventually a portfolio of companies — as a single, durable, self-governing system, where the software that operates the business is built, reviewed and improved by the system, within a leash a human controls.

Silas is the operating intelligence behind Shelterwood, a small holding company. It is one agent, not a cast of personalities. It is the same mind whether invoked from a laptop, woken by a scheduled tick on an always-on machine, or reached through some future runtime. What makes it continuous is not a long-running process but a durable memory that every session reads on the way in and writes on the way out. The process is disposable; the memory is precious. That inversion — continuity in the record, not in a kept-alive process — is the first design decision, and much of the rest follows from it.

The honest summary up front: the planning and reviewing machinery is real and running; a single unit of work can already go from plan to built-and-merged code without a human in the middle; and the one switch that would make it fully autonomous — building unsupervised across the whole business — is off, and stays off until it earns the right to be turned on.

The thesis: the loop is the unit of construction

The founding idea is borrowed and then taken seriously. Every function of a business should be built as a self-improving loop rather than as an app, an org chart or a headcount plan. A well-formed loop has five stages, each able to run without a human: a sensor that sees the world, a policy that knows what it may do alone, tools it can act through, a quality gate that checks its work, and a learning stage that captures where it failed and ships the fix. What makes it self-improving is a sixth thing on top — a monitoring agent that watches the loop, sees the failure, and writes the improvement. A function that is not a loop is merely AI-assisted, a person doing the work with help, and that is the frame Shelterwood set out to reject.

Two rules of thumb keep this from becoming dogma. First, software is treated as cheap and regenerable while context is treated as precious: models improve every few months, so the code can be rebuilt, but the objectives, the accumulated knowledge and the record of what happened cannot. Second, and more subtly, infrastructure is sorted into three buckets rather than two — precious and owned (the memory, the schema, the specifications), ephemeral and regenerable (the loops, the adapters, the interfaces), and boring and rented (storage, backup, indexing). The mistake the three-bucket rule guards against is lavishing care on the boring layer. “Code is not a moat” does not mean build the substrate lovingly; it means do not build the substrate at all where it can be rented.

That is the philosophy. The mechanism that makes it more than a slogan is the loop-swarm.

The loop-swarm: many small reconcilers, no conductor

The heart of Silas is a colony of small, single-purpose loops. The law they all obey is one sentence: every loop watches one condition, runs on its own cadence, and does one thing — fill the gap, or raise the alarm. There is no orchestrator threading them together and no pipeline handing one step to the next. Loops do not call each other; each simply leaves a gap that another loop is already watching for.

The key choice is to watch for a condition, rather than trigger tasks directly. The brittle alternative — “task A finishes, so A calls task B” — breaks the instant a call is dropped, a process crashes between steps, or a step fails silently, and the real danger is that nothing notices. That is not hypothetical: the whole architecture was written down after an engine sat paused for a week because nothing was watching for the gap. Watching for the condition is self-healing instead. If a loop fails, the gap it should have filled simply persists, and the loop fires again on its next pass; the system converges on the state it is supposed to be in regardless of transient failure.

Three properties fall out of this design and each earns its keep:

• Idempotence. Because running twice on an unchanged state is harmless by construction, re-firing is always safe — which is what makes self-healing possible rather than dangerous.
• The watcher is the alarm. A loop that has gone quiet past its own cadence is itself a detected fault. An objective with no plan behind it for a week, or a measure not refreshed in a day, becomes a red light at no extra cost. Reconciliation surfaces stalls; chaining hides them.
• One gap type per loop. A broken loop blinds only its own invariant and never the others, and each loop stays simple to reason about and cheap to add.

Concretely, a loop is declared as four things — a name, a cadence, a condition to detect, and an action to take — and it is one of two kinds. A fill loop produces the missing artifact autonomously; its action closes the gap it detected. An alarm loop surfaces a condition that cannot be safely auto-filled and needs human attention; its action files a ticket rather than producing an artifact. A runner fires every loop that is due, records when each last ran, and is safe to call repeatedly. It takes a whole-pass lock, so two overlapping invocations do not collide — the second simply sees the first holds the lock and exits cleanly. It also has a dry-run mode that runs the conditions and reports what each action would do without doing it, and deliberately does not advance the last-run clock while doing so, so that a preview can never mask a silent loop.

It helps to see the loops in three layers, by what they act on.

Loops that review work

These watch the health of the existing work and are mostly alarms, with a bounded licence to tidy. One watches for a piece of work still marked in-progress with no live worker on it — a zombie claim — and resets it to ready, which is non-destructive because it only releases a dead hold. Another watches for work that no longer ladders up to any objective — orphan work — and escalates it, because orphan work is a missing demand signal, not something to silently delete. Another watches for a measure that has gone stale past its refresh window and flags it. And a maintenance loop watches for work that a later commit or changelog proves was finished but that no one closed, and closes it, citing the proving commit as its reason.

That last one is a good illustration of designing the loop against a real mess. A backlog triage found dozens of dead items, and the dominant cause — by a wide margin — was not age but shipping-and-forgetting: the fix had landed, but the work item was never closed. The durable fix is to close work at the moment it ships, which the standard build routine now does; the cleanup loop is the safety net for whatever still slips. It is bounded by hard guardrails: it never touches a live worker’s claim, and it never closes anything on age alone — only on positive evidence that the thing is done or provably dead.

Loops that plan work

These watch the space between ambition and activity, and most of them fill. If there are no live objectives to work against, one loop drafts a set of objectives with measurable key results. If an objective has no plan beneath it, another drafts the plan. If an approved plan has not been broken into concrete units of work, another does the breaking-down. What matters is that these do not chain: the loop that drafts objectives ends at drafted objectives, and it is a separate watcher — the one looking for an objective with no plan — that later notices and picks up.

There is a strict discipline on the measures these loops write. A key result must be scoreable: it has to name a number and a metric, or an argued case that could later be backed by concrete artifacts. The review step that approves a draft rejects any measure that could not later be scored. This is deliberate, because it makes a whole category of self-deception structurally impossible — you cannot set a target that you could quietly declare met without evidence.

Loops that do work

These take a ready unit of work and build it, running the standard build-and-merge routine that turns a specification into reviewed, merged code. This is the one layer that is deliberately held. The loop exists and the routine works, but the switch that lets it run unsupervised across the business is off, and only a human turns it on. Planning may automate; doing waits.

The meta-loop

Sitting above all of them is a loop whose only job is to watch the watchers. If any loop has fallen silent past its declared cadence — with a small grace margin, so a loop that just crossed its deadline is not falsely accused — that silence is itself a gap, and the meta-loop raises the alarm. This is the guard that was missing the week the engine died unnoticed, and it is treated as non-negotiable.

One design reflex runs through the whole swarm and is the reason it keeps growing. When something goes wrong, the deliverable is not the fix but a new single-purpose loop that makes that class of wrong impossible to sit unnoticed again; the manual correction is merely that loop’s first run. And prune and plant are kept as separate gardeners — a loop that both removed dead work and generated missing work would be two loops in one coat, and it would forfeit the resilience the swarm depends on.

Recommend, review, act: the safety spine

A loop that only surfaces a problem is safe by construction; the worst it can do is cry wolf. A loop that changes something — closes work, merges code, deletes, spends — is a different matter, and here Silas follows one discipline without exception.

An acting loop never acts on its own judgement. It splits into three roles. A recommender detects the condition and emits an evidence-bearing recommendation into a durable, append-only record — not an action, a proposal with its reasoning attached. An independent reviewer, a separate agent, then examines that recommendation adversarially: its job is to try to refute it, not to rubber-stamp it, and it checks the evidence rather than trusting the recommender’s say-so. Only a recommendation that survives review is handed to an actor, which executes just the approved set and still passes through the same enforcement checks every other action does. Alarm-only loops and non-consequential resets may skip this gate; anything that destroys or ships may not.

This is a machine-checked gate rather than a human one, which is the point — it keeps the swarm autonomous while making its mutations safe. Its value shows up most clearly when it catches something. In building one of the acting loops — a classifier meant to wave through low-risk changes so they could merge without a human — the adversarial reviewer sent the recommendation back three times before the classifier was allowed to act. Each time, it had called a change safe that was not. That is not the gate failing but doing its job, catching the mistake before anything reached the real world; the classifier earned its licence to act only after its judgement had been checked and found sound often enough to trust.

The same shape appears at the code-merge boundary. When a built change is a candidate to merge itself without a human keystroke, two fail-closed gates stand in order. The first is the hold-list, described below, which ensures this step sees only changes already judged routine. The second is a carve-out denylist: regardless of how routine the change looks, if its diff touches any safety-sensitive area — the system’s own constraints and specifications, the enforcement machinery, secrets, the build and release configuration — the whole change is ineligible and escalates to a human. A single carved-out file taints the whole change, and a diff the system cannot fully inspect is ineligible too. Every auto-merge writes a durable audit record and prints the one-line command to revert it. The barrier relaxes for routine work and holds firm for anything that could weaken a control.

The memory: what makes it one agent

If loops are the muscles, the memory is the nervous system, and it is the part treated as precious. At the base is an append-only event log: every sensor input, decision and action lands there as an event, and every event carries exactly one tenant scope. An untagged event is rejected at write time. The governing rule is blunt — if it is not recorded in the log, it did not happen to Silas — and the log is the single window through which the system sees the world. Above the log sits durable memory: consolidated lessons and facts, distilled from the stream of events, that persist across every session and runtime. On entering a scope, Silas reads this first — who Peter is, what the businesses are, what is in flight, what was decided and why — and on the way out it appends what changed. That read-first, append-on-exit path is what lets a fresh session be the same Silas as yesterday’s.

Layered on top is the structured knowledge the business runs on. Objectives and their measurable key results roll up from milestones, which in turn roll up from concrete units of work, and the units of work are tracked as a dependency graph so that what is blocked on what is legible rather than folkloric. Every business is a tenant, and the isolation is strict: one tenant’s memory, credentials and objectives never bleed into another’s, cross-tenant queries must be asked for explicitly, and each business carries its own scoped secrets. A rollup view reads across all of it to show portfolio health, but it only reads — it detects nothing itself; the loops do the detecting, and the view renders their state.

Two rules keep the memory honest rather than merely large. The first is already familiar: a measure needs evidence, not assertion. The second is that a loop which closes work but never writes back a typed lesson — a test, a rule, a playbook entry, not just prose — is treated as not yet properly formed, because it is running fast and forgetting. Compounding is not left to hope; it is a checked property.

Improving itself, on purpose

The ambition is not just that Silas runs the business, but that it gets better at running it without being told to. Several mechanisms push in that direction, and they are distinct.

A nightly compound review reads the day’s work and asks what would make tomorrow’s faster or safer — a missing check, a rule that should be written down, a lesson that ought to become a test. It feeds a proposals pipeline governed by the same recommend-review-act discipline as everything else, with anything touching the system’s own constraints held for a human. A separate weekly self-audit looks at the code and the metrics rather than the day’s narrative, catching drift the daily pass would miss. A daily research loop watches the wider world — the tools, the model landscape, the risks — treating what it reads as untrusted input, so the system is not improving in a vacuum. And a monitoring agent watches across the whole loop: the sensor inputs, the outcomes of the policy gates, the tool executions, the costs, the errors, the missed cadences, and any drift between the specifications and the code. When it sees degradation, it does not fix it silently; it proposes a fix as a human-gated change.

The organising principle behind all of it is that a learning must become a mechanism. A finding is not allowed to die as a report; it has to climb a durability ladder. A check in code beats a line in a checklist, which beats a note in memory, and the work is not done until the finding has landed as high up that ladder as it honestly can. A fixed bug earns a test that fails before the fix and passes after. A recurring human chore earns a command or a rule. A completeness miss earns a line in the checklist that scopes the next piece of work. This is the loop-swarm reflex pointed at the system itself: do not fix the instance, design the standing watcher that makes the instance impossible to miss.

One design decision here is worth drawing out. The most sensitive reviewer of all — the auditor that would eventually judge whether the system is behaving well enough to be given more rope — is planned to run on a different model family from the one Silas itself runs on. A reviewer drawn from the same lineage as the thing it audits tends to share its blind spots; independence across model families is a deliberate hedge against a whole class of correlated failure. That auditor, and its verdicts, are designed to sit outside the system’s own write-reach, so the thing being judged cannot edit its judge.

The leash: autonomy bought with recovery paths

None of this would be wise without a clear answer to the obvious question — what stops it doing something terrible? — and the answer is a specific philosophy about where autonomy comes from. Autonomy is bought with recovery paths, not with approval steps. If an action is reversible, and most work is, the default is to do it and report it afterwards, because the safety lives in being able to undo it, not in asking first. This is an inversion of the usual posture: rather than an allowlist of what the system may do, there is a hold-list of what it may not, and everything else auto-lands.

The hold-list is short and specific. Six classes stay gated: money leaving the company above a threshold or any new recurring commitment; external communications in the company’s name, which graduate channel by channel only after a track record; legal and regulatory filings and attestations, which are permanent, because a person must attest them and the system only prepares them; changes to the system’s own constraints, also permanent, because the agent may never loosen its own leash; destructive data operations; and changes to security posture, such as widening its own permissions or minting credentials. Everything outside those six auto-lands, on the logic that a git-revertible change, an audit trail and a bounded blast radius are better protection than a queue of approvals a human rubber-stamps without reading.

Underneath the hold-list is a graduated ladder for the grey area, rated by likelihood times impact. Low-impact actions run silently or after a short veto window; critical ones require explicit, per-instance approval and can never be automated. Two mechanics on the ladder are worth naming. The first is a provenance floor: any action triggered by untrusted input — inbound mail, something read off the web — is pinned to high likelihood and cannot be promoted by good behaviour, which closes off the obvious injection path where a crafted email talks the system into acting. The second is earned, revocable trust: an operator-initiated class of action can graduate to more autonomy after a run of clean approvals against an explicit predicate, but the grant is a lease that decays over time, and a single bad call demotes it instantly and quarantines it. Trust is rented, not owned.

Around that principle sit concrete, dumb, reliable guards, and their reliability comes from being dumb.

• A kill switch. A plain file at a known location that the system checks before it does anything; if it is present, the tick dispatches nothing. Beneath it sits a second, process-level cut that stops the running process outright. Two layers, deliberately, because the file is checked in software and the process cut does not depend on the software behaving.
• Spend caps enforced outside the agent. A fail-closed ledger caps spending and invocation volume per day. It is a throttle for continuous building, not a target — real spend is whatever the available on-objective work costs, up to the ceiling. A spawn that would breach the cap is refused rather than escalated, and if the ledger cannot be read, the system also refuses, because the safe default is to stop.
• A concurrency cap and isolation between workers. Only a small, fixed number of workers may run at once — a host-resource ceiling enforced by a lock a dispatch guard consults before starting a worker, not by convention. Each worker runs in its own isolated git worktree, so one worker’s changes cannot corrupt another’s, and the work is thrown away when it lands; the business does not forget, because the memory remembers, not the worker.
• A single enforcement seam. Every spawn passes through one gate where the leash is applied — the spend check, the kill check, the concurrency check, the least-privilege tool grant — so there is one place to reason about and audit, not a hundred scattered checks that can each be forgotten. Workers are given the narrowest set of tools the job needs, and the unrestricted mode that skips permission prompts is only used inside a contained environment, never on the open host.

Gates are not a special mechanism; a gate is a ticket assigned to Peter, carrying the action, the reason, the blast radius and the undo path, which he approves or rejects in one keystroke. And the approval flow runs outside the agent process by design — the agent can file the ticket but cannot grant it — which is the structural form of the rule that the agent cannot edit its own leash.

The division of labour is the thing to take away, and it is drawn deliberately. The human approves the plan and holds the true gates; the machine executes the approved plan. Even a fully approved plan does not build itself unsupervised: turning on autonomous execution across the business is a single switch, held separate from the do-then-report merge policy, and it is off until Peter chooses to flip it.

The substrate, concretely

Under the philosophy is ordinary, boring engineering. The tooling is written in Go — a compiled, conventional language chosen for reliability over novelty — and structured as a set of small capability commands behind a single gateway, each one a broker that wraps a policy around an external system rather than exposing the system raw. Silas runs on top of an open-source multi-agent orchestrator rather than a bespoke runtime, on the same rent-the-commodity logic that governs everything else; that substrate supplies the scheduling, the worker sessions and the provider abstraction, while isolation between tenants remains Silas’s own guarantee rather than something inherited, because the orchestrator’s shared store is a convenience, not a security boundary. Each business gets its own isolated scope; portfolio businesses are tenants, not snowflakes, stamped from a common template so a new one is instantiated rather than designed.

The build-and-release pipeline is local-first by policy. It runs on hardware Shelterwood owns rather than in a metered cloud; signing secrets are injected at runtime and never written to disk; a local pre-push hook runs the full test suite as the authoritative gate on every push; a version tag, not a merge or a schedule, is the deliberate signal to cut a build; and shipping software to real users through an app store remains an explicit human act. The first product — an iOS app for spin-class instructors — is the reference implementation the whole standard is drawn from, and each new project copies its shape rather than reinventing one. Observability runs on open telemetry standards, and dashboards give an at-a-glance read on the health of the loops and the state of the businesses.

Where it actually stands

Measured against the ambition, here is the honest ledger.

What is proven

A single unit of work can travel from plan, through building, review and merge, and land in the codebase unattended within its leash. The reviewing and planning layers of the swarm are running — the loops that spot dead and drifting work, that draft objectives and plans, and that keep the measures honest. The enforcement machinery is real and in force: the spend and volume caps, the two-layer kill switch, the concurrency cap, the worktree isolation and the single enforcement seam are in place and fail closed. The recommend-review-act discipline is not a diagram; it is wired into the acting loops, and it has already turned recommendations away.

What is deliberately held back

Broad autonomous execution across the whole business stays off until trust is earned. The system can organise all of the work; it does not yet run all of the work on its own say-so. Some of the more ambitious pieces — the independent cross-family auditor, fully autonomous generation of new work — exist as designs or as code kept behind a switch, waiting on evidence rather than optimism. The posture throughout is measured on purpose: no bragging until it is proven.

Why it might matter

The bet is simple to state and hard to execute. If a business is built as a legible colony of self-healing loops, over a memory that compounds, behind a leash that trades approval steps for recovery paths, then it should be possible for one person to operate far more than one person normally could — and for the operation to get quietly better on its own, rather than decaying the moment attention moves elsewhere.

It is not a lonely bet. Others are circling the same idea from different angles. One venture is buying small software businesses expressly to install an AI operator over each. Another, a used-car marketplace operating at real scale, has rebuilt itself around long-running, goal-directed agents and reports that agents now handle the overwhelming majority of its customer interactions and transactions with no human involved, converting better than the sales team they replaced. Silas is a smaller, more careful expression of the same wager, distinguished less by scale than by temperament — the insistence that the way to earn autonomy is to make everything recoverable, watch everything continuously, and let the machine off its leash one notch at a time, only after it has shown the notch was safe to give.

Whether the machine can do the work is no longer the hard question — it increasingly can. The hard question is whether it can keep doing the work correctly, unwatched, and improve itself without loosening its own leash. That is the question Silas is built to answer, and the answer is being written one small, single-purpose loop at a time.