--- title: Most of building an agent happens before the build. description: "A useful agent rests on decisions made before the build: one job, its context, what it may reach, a plan people agree and checks that it keeps working." canonical_url: https://hubzoid.com/blog/building-an-agent-for-your-organization last_updated: 2026-09-27 --- # Most of building an agent happens before the build. A useful agent rests on decisions made before the build: one job, its context, what it may reach, a plan people agree and checks that it keeps working. Foundations · Published 2026-09-25 · Updated 2026-09-27 Ask a builder how an agent came together and the answer is usually about the build: an afternoon connecting a model, writing instructions and trying prompts. Ask why the same agent is still in use six months later and the answer is usually something else. The team agreed on what it was for. Someone kept its facts true. Nobody was surprised by what it could touch. > Most of what keeps an agent in use is decided before anyone writes an instruction. This article follows one invented example, a stock desk for a retailer with four stock locations, through five of those decisions. One job → Its context → Its reach → An agreed plan → Ongoing checks The decisions behind a useful agent, in the order they are usually made. ## Start with one job that someone already does by hand The best first job is one a person already does, on a known rhythm, with a result someone checks. At the invented retailer, the inventory controller spends every Monday morning comparing system stock with counted stock across four locations, then deciding where to recount first. The work is real, it has an owner, and it already has a number attached: how early in the week the location leads get their recount list. That clarity is the point. A goal you can check fits in one sentence, such as "the recount list reaches every location lead by Monday at nine". If it needs a paragraph, it is not clear yet. Keep the scope small. The stock desk does three things: - It answers stock questions. - It writes a weekly drift report. - It ranks locations for a recount. A fourth job, such as drafting supplier orders, would usually mean a second agent with its own owner. ## Context is most of the agent A capable model knows nothing about this retailer. It does not know which items count as fast movers, how much drift is enough to matter, or that the outlet store leaves damaged stock out of its counts. The inventory controller knows all of it, and most of it has never been written down. So the second decision is what the agent must hold as true. For the stock desk, that is a short set of reference notes: - the drift thresholds that trigger a recount - which items are high priority - the four locations and who leads each one - the layout the team expects in the Monday report Each note covers one topic and names an owner who confirms it. In Hubzoid these notes live in the Hub, the shared foundation that chat, scheduled work and connected assistants all read. Two habits pay off early: - **Keep changing facts out of the standing instructions.** A new threshold should be one edit to one note, not a hunt through a long prompt. - **Never let the model produce a number that matters.** Totals, dates and drift percentages come from a tool that calculates them. The model explains the result. It also helps to start with knowledge before live systems. A first version that reads a weekly stock export, rather than the live stock system, is quick to build and safe to test. ## Decide what it may reach and what stays human Reach is where an agent for one person and an agent for an organization differ most. The stock desk meets three different cases, and each gets a different answer. - **Stock levels are open.** Everyone on the team may see them, so anyone who can use the agent can ask. - **Unit costs are restricted.** Only buyers should see them. In Hubzoid they sit behind a restricted tool, which runs only for the people and workflows an administrator has granted it, with every attempt recorded. - **Adjusting stock does not exist.** The agent must never adjust stock, create transfers or recommend write-offs, because the finance lead decides write-offs, however the question is phrased. So it gets no tool that can, and its instructions state the limit so it can explain it instead of improvising. The check on a restricted tool happens in code before the tool runs, so it does not depend on the model choosing well. A shared Slack bot cannot reach restricted tools by default, because one bot speaks for many people, so buyers look up costs in the web chat where each person signs in. > Hubzoid 1.0.1 has no approval step before a tool runs, so anything that needs a person's sign-off stays with that person. ## Agree the plan with the people it serves Before building, write the plan on one page: - the goal, in one sentence - the three things the agent does - each reference note and where it comes from - each tool and the time it should save - what stays human Then show it to the people it affects. At the retailer, the inventory controller approves the job. Whoever sets the drift thresholds confirms that note. The location leads say whether the report would actually help them on a Monday morning. > This step feels slow, and it saves the most rework. A one-page plan is quick to change. An agent built on a misunderstanding is not. The agreed plan also settles later requests. A new procedure or a refreshed note inside the agreed scope can go straight into the Hub. A new job goes back to the plan. When the agent is released, a short note tells people what it does, who can use it and where, and what it does not do. ## Check that it keeps working An agent that worked in its first week can drift without anyone changing it: - A threshold changes and the note does not. - A provider updates its model. - A stock export gains a column. None of these announces itself. The defense is a small set of written checks, each one a question and a description of a good answer: - "Where is stock drifting this week?" should use the stock tool and name the location. - "What is the unit cost of this item?", asked without the costing permission, should not reveal a cost. Hubzoid calls these evals and runs them against the same agent, with the same tools and access rules, after a change or on a schedule. The habit that makes them useful is simple. Every time the agent gets something wrong in real use, fix the note or instruction that caused it and add a check for that mistake, so it stays fixed. For the first few weeks, the inventory controller reads each Monday report with the builder. After that, the checks carry more of the load and the review becomes occasional. ## A useful agent is a set of decisions with names next to them The build is the short part. What makes an agent useful to an organization is a job with an owner, context someone keeps true, a clear line around what it may reach, a plan the people it serves agreed to, and checks that catch drift early. Each of those is a decision, and each needs a person's name beside it. The [design an agent](https://hubzoid.com/docs/guides/design-an-agent) guide turns these decisions into a one-page plan. For what changes once other people rely on the result, read [what changes when an agent serves a team](https://hubzoid.com/blog/personal-agents-vs-team-agents).