An inventory, not a feature list
The inventory comes first, because without it a conversation about agents is marketing.
The agent runs the inbox: reading incoming mail, searching the archive, preparing replies. It maintains the company's knowledge base — 140 pages of notes, concepts and comparisons today — and searches it two ways, keyword and vector, because full-text search alone does not survive contact with real questions. It keeps a research archive: 94 reports, each dated and filed, so September's findings do not disappear in October.
It has a schedule: nineteen jobs that run at set times — a daily source review, a weekly digest, the backup, a market report. It runs one public Polish-language AI news service, with an edition assembled every day, and one virtual trading desk that takes a position every six hours on three thousand euros of imaginary capital, is scored against simply holding, and cannot place a real order. We read all of it through one browser interface: mail, notes, reports, fetched pages.
This is not a product capability list. It is a list of jobs that actually run, because each has an owner, a schedule, and a place to write its result.
The integrations decide
The interesting part is not that a model can write a paragraph. It is that this one has access to the inbox, to repositories, to market data and to web search — and that the access is arranged: credentials held outside the agent, narrow permissions, and irreversible actions requiring a human to agree.
This is where, in our reading, AI deployments inside companies stall. Not on the model. On the fact that nobody connected the tool to the system the company actually works in, and that after the first week there was no one left to keep it alive. A purchased licence does not answer that question, because a licence has no hands.
It extends itself
The most surprising part — and the hardest for outsiders to accept — is that the agent writes and maintains its own tooling. The search over its own knowledge base, small scripts for fetching data, the backend of the interface we read its work through.
This does not come from a requirements list written at the start of a deployment. It comes from a real job revealing, by itself, that a tool is missing.
The boundary is clear: the tooling lives in a repository with change history, so every modification can be traced and reverted, and decisions about what the agent may reach are made by a person. The agent proposes and does work; it does not widen its own permissions.
What it does not do
Without this section the rest would be advertising, so here is what does not work, just as concretely.
**It needs a human for judgement and for anything irreversible.** It can prepare a reply, but sending it to a client, changing a configuration, spending money — that stays with us. Not out of caution, but because of accountability: someone has to put their name to it.
**It is wrong with confidence.** Our own publishing process has a quality check that blocks publication by default, for one reason: a draft appeared that passed every shape check and was, in substance, a refusal to write the text. It looked correct. Without a check that stops everything it cannot vouch for, it would have been published. A model does not signal doubt in its tone — it signals it in content you have to learn to read.
**It forgets anything that was not written down.** Knowledge that never reached a file does not exist. Which is why the most important part of this setup is not the model's memory but what stays on disk.
**Scheduled jobs die quietly.** One of our weekly jobs ran, produced its report, and delivered it nowhere, because its delivery target had been wrong from the start. Nobody noticed until we read the schedule table: no crash, no alert, just work that no one ever saw. It is the same problem we described in the service-schedule piece — supervision is either somebody's job or it does not exist.
**It has limits its operator sets.** One night five jobs started at once on a four-core machine and the computer had to be restarted by hand. Once an agent can hand work to itself and to other agents, how much runs in parallel becomes an infrastructure decision rather than an implementation detail.
The bill
The cost of this setup has three parts, and all three are visible in our own accounting: model calls metered by token (variable, proportional to the work actually done), a small always-on machine, and the operator's hours. Here that third line is the largest — and it is what decides whether any of it works.
We are not putting a monthly figure in this piece, because it is not a number that compares without context: our work includes writing this text, so our bill covers things a client does not buy. The shape matters more than the figure: the model is cheap and variable, the machine is cheap and fixed, and human attention is expensive.
What this means for your company
We would start from three decisions.
Give the agent real access to a real job. Not a demo, not a data-free test environment — one task that genuinely has to be done, with access to the systems the company works in.
Decide who looks at the result. If it is not in someone's responsibilities, the project will stop in week two and we will call it a lack of innovation culture.
Budget for upkeep, not just building. This is not a project with an end date. It is a role that has to be covered — even when the agent occupies it.