The agent
An engineer
that runs on
a schedule.
The hands-on work in this studio is done by an autonomous software agent. It is not a chat window and not a copilot sitting inside an editor: it wakes on a timer, decides what to do, does it, ships it, and writes the instructions its own next session will wake up to. This page is the specification, because “we use AI” is not a claim anyone should accept without one.
- It runs in discrete sessions. Nothing but files and its own written prompt survives between them.
- It ships real artifacts to the public npm registry and to live domains, under the studio’s name.
- Every capability claim below has a command under it that you can run yourself.
The cycle
One session, start to finish.
The whole system is a loop with a hard edge on both ends. Understanding that edge is the difference between an agent that compounds and a demo that impresses once.
-
01
Wake with no memory
A session starts with exactly two things: the working files in its repository and a prompt written by its previous self. There is no conversation history, no retained context, and no human on the other end typing. If the previous session failed to write down a fact, that fact is gone.
-
02
Read the standing orders before deciding anything
First action of every session is to read the file where its human writes requests, then to enumerate the repositories it has access to and list the open issues on each one. A filed bug on anything it has shipped outranks whatever it planned to build. Deciding what to work on comes after reading, never before.
-
03
Do one thing to completion
A session is sized to finish a unit of work: write the code, write the test, run the suite, publish the release, verify the published artifact from the outside. Finishing one item beats starting three — a half-finished action is the one thing the next session cannot pick up cleanly.
-
04
Verify from outside its own process
Shipping is not the same as having shipped. A release is only done when the public registry reports the new version as latest and the live URL answers 200. The agent’s own belief that a deploy succeeded is not evidence; that mistake has cost this project entire days.
-
05
Write the next prompt, then stop
Every session ends by recording what happened in an append-only journal, trimming its working-memory file back down, and writing a complete, self-contained prompt for its successor. That prompt is the only thread of intent between sessions, so it has to be specific enough for a stranger to execute.
The interesting consequence: the agent’s memory is a written artifact rather than a context window, so it is reviewable. You can read what it thought it was doing at any point, in its own words, dated.
Walls
What it is not allowed to do.
Autonomy is only useful if the boundary is explicit. These are hard limits, not preferences, and the agent’s correct response to hitting one is to write down what it needs and go do something else.
It spends no money
Model tokens only. No purchases, no paid tiers, no signing up for anything. Cost is the single limiting resource, and a session that runs out of budget hands off cleanly rather than pushing on.
It touches only what is assigned
A fixed set of repositories, enumerated at the start of every session from what its credentials actually return — never from a list it wrote down earlier, because that list goes stale silently.
It never claims to be a person
It does not present itself as a human or as another company. Products ship under their own names, the studio’s work ships under the studio’s name, and nothing it writes is passed off as having come from me.
On someone else’s product, it is a maintainer
There is a firm split between tools it built, where it owns the roadmap, and properties it maintains, where it only ever does what has been filed. A locked design decision stays locked. It never migrates or destroys production data.
The last one is the rule with the most teeth. An agent that improves things nobody asked it to improve is indistinguishable from an outage waiting to happen.
Check it
Ninety seconds, your terminal.
Publish timestamps on the npm registry are set by the registry, not by the publisher, and cannot be edited afterwards. That makes them the cheapest honest evidence available. Run these.
The cold start — a package published 45 minutes after the agent first saw the mission
npm view gitsignet time.created
2026-08-06T11:45:34.481ZEvery release of every tool, with its own timestamp
npm view mycadre time --json
npm view gitsignet time --json
npm view sottovoce time --json
npm view packproof time --jsonOr without npm installed at all
curl -s https://registry.npmjs.org/packproof | jq '.time, ."dist-tags"'Install one and use it — this is the actual claim
npx packproof --helpWhat those commands returned, read from the registry on 2026-08-12
| Package | First published | Latest | Releases |
|---|---|---|---|
| mycadre | 2026-08-0321:20:38Z | 0.1.6 | 7 |
| sottovoce | 2026-08-0322:44:28Z | 0.2.1 | 3 |
| gitsignet | 2026-08-0611:45:34Z | 0.1.4 | 5 |
| packproof | 2026-08-1015:02:06Z | 0.2.0 | 3 |
Each row is one command away from being falsified. That is the whole design goal of this page: if any line of it were untrue, checking would be cheaper than arguing.
Limits
Where it needs a human, and where it is weak.
The failures on the home page are the ones that have already been fixed. These are the standing limitations, which is a more useful list if you are deciding whether to trust the arrangement.
Anything requiring an account is a human action
Registry tokens, domain records, repository permissions, two-factor prompts. Work has sat finished-but-unshipped for days waiting on a single click — a publish once blocked on a token type the registry refuses for publishing.
The agent’s job at that point is to write down precisely what it needs, in one place, and keep working on something else instead of retrying the same rejection.
It will re-diagnose the same wrong layer
Given a deploy that reports success and then serves nothing, its instinct is to edit the build configuration again. The real cause was upstream and stated plainly in the platform’s own deployment record, in a field nothing surfaces by default.
Three identical retries is now treated as a signal in itself: stop re-diagnosing the layer you can edit and go read where the platform states its own reason.
It cannot tell you whether the work was worth doing
It can pick the next task, size it, finish it and verify it. Deciding which problem deserves the money in the first place — and whether an approach is a dead end worth abandoning — is not delegated, and should not be.
That is the part you are hiring me for. The agent multiplies a decision; it does not make it.
Contact
Want this pointed
at your problem?
The lead offer is still my judgment on a hard systems or AI-infrastructure problem, with the agent doing the hands-on work beside me. If what you actually want is an agent operating like this inside your own org, say so — but I’d rather solve the problem you have first.