Agentic AI and the shape of small-team work

AI · 2026-07-19 · 8 min read · 1773 words

By ESPYCRUX, Studio

When a model can take actions rather than only produce text, the thing you hand over stops being a question and becomes a task. That sounds like a capability story. In practice it is a specification and verification story, and the bottleneck moves to the person doing the checking.

For most of the time we have been using language models, the interaction had a fixed shape. You described a problem, you got back text, and you did something with it. The model was a very fast colleague who could not touch anything. Whatever it produced, you carried across the gap into the real work yourself.

Agentic tooling closes that gap. The model reads files, runs commands, calls APIs, checks whether the thing it did worked, and tries again when it did not. The unit of delegation changes from "answer a question" to "complete a task". That is a genuine difference in kind, not a better autocomplete, and it is worth thinking about carefully rather than either dismissing it or getting excited about it.

We are a studio of a few people running six public properties, three of them finished. We use these tools daily and find them useful in specific places. This is what we think a team our size actually needs to understand, including the parts we are still unsure about.

What changes when you can hand over a whole task

The obvious change is throughput, and it is real. Work that used to be a sequence of small decisions — read this, change that, run the tests, read the failure, change it again — can run without you in the loop for each turn.

The less obvious change is what you now have to write down.

When you delegate a step, the context is in your head and you supply it turn by turn. You can be vague, because you are right there to correct course. When you delegate a task, everything the work depends on has to be either in the instruction, discoverable in the codebase, or absent — and if it is absent, the agent will invent something plausible to fill the hole. It will not stop and ask, because it usually cannot tell the hole is there.

This is why the failure mode of agentic work is rarely incompetence. It is confident work performed against the wrong specification. The output looks finished. The tests you asked for pass. It is solving a slightly different problem from the one you had.

So the skill that suddenly matters is not prompting in the sense of finding magic phrasing. It is the older and duller skill of writing down what "done" means before starting: what the change should do, what it must not break, what the boundaries of the task are, and how anyone would know it worked.

The constraint is not the model any more

For a while the limiting factor was raw capability. If a model could not do something, no amount of scaffolding around it helped.

That is less often the binding constraint now. When agentic work goes badly for us, the cause is usually one of these, in roughly this order:

• The tools are poor. The agent can only act through what you give it. If your test suite is slow, flaky, or does not cover the thing being changed, the agent has no way to tell success from failure, and neither will you when you review it.
• The permissions are wrong. Too narrow and it stalls asking for things. Too wide and a mistake reaches further than it should.
• The feedback loop is missing. An agent working without a signal — no tests, no type checker, no linter, no way to run the thing and look at it — is guessing with extra steps.
• The task was under-specified. See above.

None of those are model problems. They are environment problems, and they are the same environment problems that make human work slow, which is a slightly deflating but useful observation. Teams with good test coverage and fast feedback get more out of agents. Teams without get an efficient way to produce work nobody can check.

The practical version of this: if you want to get more out of agentic tooling, the highest-value thing you can do is usually not switching models. It is making the verification cheap.

The review bottleneck

Here is the part we did not expect and now think is the central issue.

Reading and verifying work is often slower than doing it. That is true of human work too, which is why code review is unpleasant, but with an agent the ratio gets much worse. Generation is now almost free. Verification costs exactly what it always did.

So a small team can find itself in an odd position: a large volume of plausible output, produced in an afternoon, and one person who has to decide whether any of it is correct. The work has not disappeared. It has been converted into review work, and review work is harder to do well because it is passive, it is easy to skim, and plausible-looking code is specifically the kind that defeats skimming.

What makes review better or worse, in our experience:

The pattern in that table is that the things which make review cheap are mostly decisions you make before the agent starts. Once you have a nine-file change in front of you, your options are to read all of it properly, or to trust it. There is no third thing, though "skim and hope" is a popular impostor.

We have found it worth deliberately capping the size of what we hand over, even when the tool could plainly do more in one go. A change you can review in ten minutes is worth more than three changes you review in forty and half-understand.

Where agentic work genuinely fits

The pattern that holds up for us is: well-specified, verifiable, tedious, low blast radius. All four, not three.

• Well-specified — you can state what done means without hand-waving.
• Verifiable — there is a cheap oracle. Tests pass or fail. The page renders or does not. The output matches the schema.
• Tedious — the work is mechanical enough that doing it yourself is a poor use of an afternoon.
• Low blast radius — if it is wrong and you miss it, the damage is bounded and reversible.

Things that fit that shape for a studio like ours: migrating a component to a new API across many files; writing the boring half of a test suite; converting data between formats; scaffolding a tool from a pattern you have already established four times; tracking down where a value comes from in an unfamiliar part of the codebase; and the whole family of tasks that are really "read a lot of things and report back", where the report is cheap to spot-check.

Where it does not fit:

• Judgement calls. What to build, what to charge, whether a feature is worth the maintenance. An agent will produce a confident recommendation. Confidence is not the scarce input here.
• Work with no cheap oracle. If the only way to know whether the output is good is careful human reading — prose in your own voice, design decisions, anything where "correct" is a matter of taste — you have not saved anything. You have moved the effort to review, where it is more tiring.
• Anything touching production without a rollback. Not because agents are uniquely dangerous, but because the failure mode is fast. A mistake a human makes at human speed usually gets noticed partway through.

There is a middle category we are still working out: tasks with a slow oracle. Performance work, anything where the feedback arrives days later in analytics. Agentic tooling does not obviously help there, and we do not have a confident view on it yet.

Permissions and blast radius

The permission question is the one we would encourage any small team to think about before it becomes urgent.

An agent acts with whatever access you give the process it runs in. That is the whole security model, and it is less abstract than it sounds. If the agent can reach your deployment credentials because they happen to be in the environment, then the blast radius of a misunderstood instruction includes your live site.

We do not have a sophisticated setup, and we are not going to pretend otherwise. What we practise:

• Agents work in a checkout, on a branch, never against anything live.
• Deployment stays a separate deliberate act by a person, after review.
• Secrets are not in the environment the agent runs in unless the task genuinely needs one, and then only that one.
• Anything destructive — deleting files, dropping data, force-pushing — is a thing we confirm, not a thing we auto-approve because the prompts got annoying.

That last one is the honest weak point of every permission system: approval fatigue. Prompted often enough, everyone starts clicking yes. The fix is not more discipline. It is arranging things so the agent rarely needs to ask, by giving it a sandbox where the dangerous options are not present at all.

The thing we keep coming back to

Agents make it very easy to produce a large amount of plausible work.

That sentence can be read as praise or as a warning, and we mean it as both. Producing plausible work quickly is genuinely valuable when you have a way to tell plausible from correct. When you do not, you have built a machine for generating things you will have to trust without checking, and trust without checking is how small teams accumulate the kind of problem that surfaces six months later.

Our position is that this is a good trade in the places where the four conditions hold, and a bad one everywhere else. It is not a general-purpose upgrade to how work gets done. It is a specific tool that pays off in proportion to how well you have built the environment around it — which means the boring investments, the tests and the types and the clear task boundaries, have quietly become the thing that determines how much value you get.

We would rather say that plainly than pretend we have this fully worked out. We are a few months into taking it seriously, and the parts we are most confident about are the limits.

Tags: ai, agents, small teams

ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.