Your agents need a company around them

Agents already write code for people. An engineer can hand one a bug and get back a useful change. Getting that change accepted and shipped still often depends on the engineer supplying context, sorting out access, and carrying the work through review.

Companies have spent years building support around the people they hire: working tools, accounts, shared instructions, and a process for accepting their work. When that support is missing around an agent, the person using it has to fill the gaps.

Putting agents to work inside a company makes providing that support a management responsibility.

Joel Spolsky made a broader version of this argument in The Development Abstraction Layer in 2006. Developers depend on an organization that supports their work and turns it into products customers can use.

The work around the task

Take a small bug fix. Before an agent can do useful work, it needs a repository it can read, a working development environment, and a description of the result someone wants. Before that change can ship, it needs evidence that the relevant checks ran and a person or process with authority to accept it.

A demo can leave these details off-screen. A team using agents every day has to answer them repeatedly.

Which account opens the pull request? What can that account access? What happens when a test fails or the reviewer asks for a change? Who notices if the work stops while waiting for an answer?

If the process has no answer, an engineer supplies one. They paste the context, prepare the machine, carry the review comment back, and remember to check again tomorrow. The agent may have done its assigned step well. The engineer still owns the work between the steps.

Six things to prepare

A job. “Help with engineering” leaves a lot to invent. Be specific: “Take a well-scoped issue, make the change, run the required checks, and return a pull request for review.” The job description should also explain when to ask for help and which decisions belong to someone else.

Working tools. Give it a prepared computer and the software the job needs. For a code change, that includes a way to build, run, and inspect the project. A repository alone is rarely the whole environment.

Its own identity and appropriate access. Give the agent accounts that make its work distinguishable, with access suited to the job. Someone should own the decision to grant more.

Written instructions. Put the process where the team can read and improve it. The checks, handoffs, and definition of done should survive the conversation that started the task.

Someone who can accept the work. Name who can approve the result and what happens when they ask for changes. An approving review in GitHub should be something the process recognizes and acts on.

A record. Keep the request, result, checks, review, and corrections available to the next person. They should be able to understand what happened without asking someone to reconstruct a chat from memory.

The same preparation applies outside engineering. An agent producing a weekly campaign report needs to know which data to use, what questions to answer, and who reviews it. Access to an advertising account doesn’t answer those questions.

These are the things we build around agents at Wallfacer. An agent has a role, computer, and access. The handbook holds shared instructions. A playbook connects the actions and waits that carry a process forward.

Someone still has to know what the job is, which systems it should reach, and where the human decision belongs. Software can make those choices explicit and reusable.

Keep the job outside the model

A better model may make an agent more capable. The team should still know what its job is and how its work gets accepted.

That gives you a design test: if you change the model, the role, instructions, access decisions, and history should remain available. You will still need to evaluate how the new model performs. You shouldn’t have to reconstruct the company’s process from the last model’s conversations.

Look for the work between the steps

Start with one recurring job your team already knows how to evaluate. Follow it from the request to an accepted result. Notice where a person has to supply missing context, fix access, relay a review comment, or remember to check back.

Each of those moments points to something you can improve: add the instruction, prepare the environment, fix the access, or give the waiting work a next step.

Some human involvement belongs in the process. Someone should make the decisions you’ve reserved for them. The support is working when that person has what they need to decide, and the work can continue afterward.

We still have gaps at Wallfacer. Preparing a computer for a new codebase takes work, and there are moments when a person waits on the machine. Those are product problems for us to reduce. The point of this support is to make work easier to hand off, and we should judge it by that standard.

Bring us a process. We can walk through one job your team knows, the tools it needs, and the decisions that should stay with your team.