Building in
the age of agents.

A model can read a hundred-page contractor bid in seconds and give you a clean summary of it. That stopped being interesting a while ago. What it cannot do on its own is tell you whether two of those bids are describing the same building.

That gap is the whole job.

We built a bid-leveling tool for an owner’s representative firm in Florida that manages restoration work for condominium and HOA boards. Seven proposals arrive for a project. Each contractor organizes its numbers the way its own estimating shop prefers. The person who eventually has to choose is a volunteer board member with no construction background and a fiduciary duty for a multi-million-dollar award under Florida’s post-Surfside statutes. Getting a ranked list was never the hard part. Getting a ranked list that member could defend was.

WHERE COMPARABILITY ACTUALLY COMES FROM

Comparability is manufactured. It is not sitting in the documents waiting to be extracted.

Take one scope of work. One bidder prices it as a line in the base bid. Another moves it to an alternate, so it only appears if the board elects it. A third carries it as an allowance, which is a placeholder with a number attached rather than a price. A fourth writes it into the exclusions and never mentions it again. Four honest bids, four different totals, and none of the differences are about who is cheaper.

So the first real decision is the taxonomy. We mapped line items to CSI MasterFormat, extended for restoration trades. The standard covers the industry; the extension is where the actual work went, because the mapping is a judgment about what a given line item is, made once and then applied consistently.

The second decision is to keep base bids, alternates, allowances and exclusions in separate buckets and never let them merge. Collapse them and the word “lowest” stops describing price. It starts describing which bidder chose to include the most.

Neither decision is a modeling problem. Both are domain knowledge that somebody has to write down before any automation is possible.

WHAT THE COMPUTER DOES AND WHAT THE HUMAN DOES

We drew that line on purpose and then made the tool enforce it.

Anything mechanically present in the bid matrix is computed: totals, price per square foot, price tiers, variance, ranking. Arithmetic does not need an opinion, and asking a model for one is how you end up with a number nobody can trace.

Anything that is judgment stays labeled as judgment. The cost baseline and the square-footage basis are supplied by the firm’s estimator on every run. They are not inferred, and they are not remembered from last time. The qualitative ratings are drafted by AI and then reviewed, and overridden where needed, by a person before a board sees any of it.

And when a required input is missing, the tool stops and asks. It never guesses.

That last behavior sounds like a small implementation detail. It is the difference between a tool a professional will put their name on and a tool a professional has to check behind.

BUILD THE CHECK THAT CAN EMBARRASS YOU

On the validation project, the independence check found that the supposedly independent cost baseline matched one bidder’s subtotal almost exactly. That is a strong signal the yardstick had been anchored to the number it was supposed to be measuring. The tool also surfaced a duplicate bid from the same contractor carrying two different totals. Of the seven bidders scored, three were set aside with documented reasons rather than quietly vanishing from the comparison.

The useful pattern there is not “add validation.” It is which direction the validation points. A check that only interrogates the other party’s data is decoration. The checks that earn their place are the ones capable of calling your own inputs into question, because those are the errors nobody else in the process is looking for.

THE OUTPUT HAS AN AUDIENCE WITH LIABILITY

The reader of this work is a volunteer, not an analyst, and they carry real exposure for the decision. So the handoff package includes a plain-English assumptions and methodology memo that separates hard arithmetic from informed judgment, section by section, and states which numbers still need confirmation before an award.

That memo is not a formatting pass at the end. It is only writable because the pipeline was built so every number can be traced back to the line item it came from and the rule that moved it. Defensibility is a constraint on the architecture. Bolt it on afterwards and you are writing a document that describes a process you cannot actually reconstruct.

WHAT GENERALIZES

Document reading is now a commodity. Comparison is not, and it is not a model problem. It is a rules problem, and the rules are domain knowledge held by experienced people who have usually never been asked to write them down.

If you are pointing a model at a stack of documents and expecting a ranked answer, the question to settle first is what would make any two of those documents comparable, and who decides. Answer it properly and most of the build is mechanical. Skip it and you get a confident ranking of things that were never the same.

One more thing worth remembering about how this landed. The firm noticed the time savings first: leveling that took hours of copying and reformatting now takes minutes. That got their attention. What won them over was the checking, which is slower to appreciate and harder to demo. Speed gets you the meeting. Catching the error that would have gone to the board is what gets a tool adopted into the standard process.

Four people. Ad campaigns running to audiences across a region, in several languages. A whiteboard with the workflow they wanted already drawn on it.

What was missing was not the idea.

The client is a nonprofit digital-outreach organization whose Asia-Pacific team was carrying all of that. The front half of their loop, the content and the campaign work, consumed everything they had. The back half kept going cold: following up with the people who responded, reconciling campaign data against donor records, reporting on any of it. Their lead’s framing was that they had the map but not the hands to walk it.

DIAGNOSE THE GAP BEFORE YOU PRESCRIBE

A team that does not know what is possible and a team that knows exactly what it wants and has no capacity to act look identical from the outside. Both are stuck. They need opposite things.

The default consulting move is to hand over an automation plan. For this team that would have been the wrong prescription delivered competently. They did not need to be told what to build. Telling them again would have added a document to the pile they already had no hands for.

So the diagnosis came first and the tooling second: this was a capacity gap, not an awareness gap. Everything after that followed from it.

AUDIT THE LICENSES BEFORE YOU DESIGN THE CURRICULUM

We audited what the team actually held, so that every recommendation matched software they could really use. We also built a license contingency into the workshop design, so the three days still worked if the premium licenses did not land in time.

That is less about Microsoft than it looks. An enablement plan whose critical path runs through somebody else’s procurement decision is a plan with a hole in it. Design for the entitlements on hand and treat the upgrade as upside.

NAME THE AGENTS IN BUILD ORDER

The opportunity map we produced named the highest-value builds in priority order rather than presenting a portfolio of possibilities.

A roadmap listing a dozen opportunities gets read once and admired. A roadmap that says build this one first, then this one, gets used, because a team with no spare capacity cannot afford to spend any of it choosing.

THE WORKSHOP WAS A BUILD, NOT A BRIEFING

Three days, onsite, hands on keyboards. The stack was deliberately plain: Planner as the task backbone, Power Automate as the plumbing, a Copilot agent grounded on the team’s own SharePoint content, and a Power BI builder day.

Plain was the point. When the binding constraint is capacity, every tool you introduce becomes a maintenance cost that lands on the same four people. Elegance that costs them an afternoon a week is not elegance.

The material got re-tweaked each evening around whatever that day had actually surfaced. A curriculum that survives contact with a room completely unchanged probably was not paying attention to the room.

GROUND THE FIRST AGENT IN THEIR OWN MATERIAL

The team came away building. They stood up a communications agent in Copilot, grounded on a SharePoint knowledge library of their own communication style, tone and standard operating procedures. The opportunity map had named that agent; they built it.

Grounding it on their own material is what separates an agent from a generic assistant, and it is also what makes the value obvious on day one to people who were skeptical on day zero.

THE PROOF IS WHAT THEY BUILD THAT YOU DIDN’T PLAN

Then they went past the roadmap entirely. They built a subagent team in Claude Code to handle translation, updating large numbers of files across many languages. An operation that took days by hand now takes minutes.

Nobody scoped that. It was not on the map, and we were not in the room for it. That is the actual test of whether enablement worked: the team crossed onto a second platform on their own initiative and got something running.

It is also worth noticing what they built. Not one agent. A team of agents with the work divided between them, which is a harder thing to design and a much bigger multiplier for four people.

WHAT GENERALIZES

When the constraint is capacity, the deliverable is capability. A document is a deliverable that still needs hands.

Cross-platform turned out to be a consequence rather than a stance. Copilot made sense because the work already lived in M365. Claude Code made sense because the file-scale language work needed something else. Committing to one vendor’s complete answer would have cost this team the second half of what they now have.

And the honest limit. The team’s hardest constraint is not software; it is getting people to support the work, and no agent fixes that. What the agents are doing is showing up in the team’s efficiency, which buys back hours that can go toward the constraint that actually matters. The engagement was pro bono.

ARA has one human. The rest of the firm is a roster of AI specialists, each with a written job description, a defined scope, and a specific set of tools it is permitted to touch.

This note is about what that is like to operate, including the parts that do not work.

THE ORG CHART IS A FOLDER OF FILES

Every member of the team is a file. The file holds a name, a persona, what the role is for, what it must never do, and which tools it can use. There is a chief of staff, a head of people, a researcher, a designer, a strategist, a delivery and business-operations lead, a data scientist, a solution architect who builds, a technical reviewer, a web developer, an education lead, and a handful of domain specialists added for particular kinds of work.

Adding a capability is not a metaphor for hiring. It is an edit to a folder, and because the folder is under version control you can read back why a role exists and what it was originally scoped to do.

The part that turned out to matter more than expected is that roles get researched before they get written. The researcher produces an evidence-based brief on what a strong human practitioner in that domain actually knows, uses and produces. Only then does the head of people turn that brief into a role definition. Skip that step and you write a job description out of your own assumptions about a field you do not practice, which is exactly the failure a one-person firm is most exposed to.

ONE RULE DOES MORE WORK THAN ANY OTHER

The orchestrator does not do the work.

The chief of staff routes, briefs, sequences hand-offs, and brings results back, and does not write the deliverable, run the analysis, or make the domain call. That is a standing directive rather than a preference, because the temptation to just do it is constant and it is strongest exactly when the work is urgent.

The reason is not purity. The moment the coordinator starts producing, you lose the record of who did what, and you lose the specialist framing that made the specialist worth having.

THE ARCHITECTURE FORCES HUB AND SPOKE

Two constraints shape everything else. Specialists cannot call each other. And they cannot see the conversation that produced their assignment.

So every hand-off passes through the orchestrator, who physically carries the artifact from one specialist to the next. The org chart is hub and spoke by constraint, not by taste.

The consequence is that the brief is the product. If a file path is not named in the brief, the specialist does not have it. If a hard rule is not carried into the brief, it does not apply. The most common failure mode in this firm is a thin brief, not a weak specialist, and it took a while to stop misdiagnosing the first as the second.

The countermeasure is a written rule that on an ambiguous brief the correct move is to come back and ask rather than guess. It works, imperfectly. A capable model handed an under-specified task will produce something plausible, and plausible is the expensive failure.

NOTHING SHIPS WITHOUT A GATE

One member reviews every deliverable before it goes anywhere. The verdict is approve, approve with conditions, or reject with remediation. Remediation travels back to the original author through the orchestrator, and the work re-enters the gate.

When the reviewer is also the builder, someone else cross-checks the work against the same criteria. A gate that reviews its own output is not a gate.

The gate covers more than code. Anything ARA-branded is checked against the brand canon. Anything outward-facing is checked for whether it reads like a person wrote it, because prose that announces itself as machine-generated is not finished work.

The honest cost: the gate is slow, and it is the single thing most tempting to skip. Its value shows up in the deliverables that got sent back, which is a hard thing to feel good about at the time.

EXECUTION IS RATIONED ON PURPOSE

There are three execution postures, and every member sits in exactly one.

Builders may write and run code, but only inside an isolated worktree, under a sandbox, with a deny list for destructive commands that always overrides whatever permission has accumulated. Authors write text and execute nothing. The reviewer runs validation and writes findings, never the artifact under review.

Builders also have to verify their own work before handing it over: turn the task into criteria you can check, then loop until the criteria pass. That does not replace the gate. It just means the gate is not the first place a problem gets found.

THE STANDARDS ARE MOSTLY ABOUT RESTRAINT

Four rules bind everyone who builds. Think first and state your assumptions; if two readings of the brief exist, present both rather than silently picking one. Ship the minimum that solves the problem, and if two hundred lines could be fifty, rewrite it. Change only what the task requires, so every changed line traces back to the request. Turn the task into verifiable success criteria and work until they are met.

Every one of those exists to stop the same behavior. A capable model will cheerfully produce more than you asked for, and most of what it adds is work someone now has to read, review and maintain.

THE SCARCE RESOURCE IS CONTEXT, NOT LABOR

This is the part that surprised us most about running the thing.

Hours are not the constraint. What every agent must carry into every session is. So new knowledge starts cheap, as a reference document read on demand. It gets promoted to a skill only when it is a repeatable procedure with a clear trigger. It goes into a specific agent’s definition only when that agent must always know it. It reaches the firm-wide charter only when every agent must. Each rung up is a permanent tax on more sessions.

Demotion is allowed and used. A rule that stops firing goes back down the ladder. Left unmanaged, the rulebook grows until nobody reads it, which is not a novel failure mode. It is the same one that produces human policy manuals nobody opens.

WHAT COMPOUNDS

Every gated deliverable produces a short capture file: what we learned, what is reusable and in what form, what idea came out of it worth developing, and what we would scope differently next time. The gate checks that the file exists.

“Nothing reusable came out of this” is a legitimate answer, and the check verifies that the question was answered rather than that an asset was produced. That detail matters more than the mechanism. A capture requirement that demands a reusable asset every time generates fake ones, and a library of fake assets is worse than no library.

The reasoning behind it is straightforward. The models are rented, and every firm rents the same ones. What belongs to ARA is the written judgment: the definitions, the rules, the captured patterns, the things we now know not to do again.

THE PARTS THAT DON’T WORK

Debris accumulates. Builder isolation creates working copies, and they pile up. At one point there were dozens of stale ones on disk, enough to start breaking shell commands outright. They now get pruned on a schedule, because nothing about that problem announces itself until it does.

Permissions drift. Every approval click appends to a local allow list. Left alone, that list quietly becomes approve-everything. It gets audited monthly. Two minutes, and the only reason it happens is that it is written down.

Background agents cannot ask for permission, so a background agent trying to write a file fails silently. Anything that writes runs in the foreground. That one cost us real time before it was understood.

Staleness is structural. Every member’s knowledge is frozen at its model’s training date, so left alone the team is confidently out of date about a field that moves weekly. Checking live sources before answering is a written rule rather than a habit, because habits are not something this team has.

WHAT ACTUALLY HOLDS IT TOGETHER

Not the agents. The agents are rented, they are the same ones everyone else can rent, and they will be better next quarter regardless of anything done here.

What holds it together is duller than that. Written definitions of who does what, so the routing question has an answer. Briefs good enough that a specialist who cannot see the conversation can still do the work, because that is the actual ceiling on quality. And a review nobody is permitted to route around.

And the human, who has not been automated out of anything that matters. One person still decides what is worth doing, what is true, what ships, and what the firm will not take on. Producing a draft now costs close to nothing, which means the scarce thing is knowing which draft was worth producing and whether the one in front of you is right.

The labor got cheap. The judgment did not move.