Part 29: Building the Agentic IT Department | Running the AI-Company

By the middle of 2026, the cost of producing working software has fallen further and faster than most operating budgets have caught up to. A net-new IT department no longer begins with a hiring plan for a large pool of engineers who hand-write every line. It begins with a fleet of capable coding agents, a small group of senior people who direct and review them, and a platform designed so that software can move from idea to production in hours rather than quarters. The change is not that agents can write code. They could do that in 2024. The change is that, by 2026, an agent can carry a unit of work from end to end: read a requirement, propose a plan, write the code, write the tests, open the change for review, respond to the feedback, and prepare a safe deployment. The economics have inverted. The scarce resource is no longer typing speed or headcount. It is clear intent, sound judgment about what is worth building, and the discipline to keep an automated system honest. ### What actually changed | Dimension | Traditional IT department | Agentic IT department (June 2026) | |-----------|--------------------------|-----------------------------------| | Unit of work | A ticket worked by a person | A loop run by an agent, supervised by a person | | Bottleneck | Engineering capacity | Clarity of intent and quality of review | | Cycle time | Weeks per feature | Hours to a day per change | | Headcount shape | Many builders, few reviewers | Few builders, many reviewers and orchestrators | | Cost driver | Salaries and coordination | Compute, governance, and oversight | | Risk profile | Slow, predictable | Fast, requires guardrails to stay safe | ### Why this matters to the executive If you build the new department the old way, you will pay for headcount you no longer need and you will move at a speed your competitors abandoned. If you build it naively, pointing agents at production with no controls, you will move fast and break things you cannot afford to break. The whole craft of running an agentic IT department lives in the space between those two failures: capture the speed, refuse the chaos. This paper is a field guide for that middle path. It assumes you are starting from zero, that you have a mandate to build, and that you will be held accountable for both velocity and control. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The traditional IT department is organized around the ticket. Work arrives in a queue, a person picks it up, carries it through a sprint, and hands it down a chain of specialists. The agentic department is organized around the loop. A loop is a single, supervised cycle in which an agent takes a well-specified intent, produces a change, and proves that the change is safe to ship. The unit of work is no longer the ticket. It is the loop, and the people who run the department are loop engineers, not ticket workers. ### The loop as the unit of work A healthy loop has a fixed shape: a clear specification goes in, an agent produces a candidate change, automated checks and a human reviewer judge it, and the result is either merged or sent back with precise feedback. The skill of the department is in designing loops that are tight enough to be safe and loose enough to be fast. This is the work we call loop engineering: shaping the inputs, the checks, and the decision gates so that an agent can run with minimal human touch but never without human accountability. ### From sprints to flow Sprints exist to batch uncertainty into predictable two-week windows. When an agent can complete a change in an afternoon, the two-week batch becomes a liability rather than a rhythm. The agentic department runs on continuous flow: small changes move individually, each one independently shippable. Planning shifts from "what will the team commit to this sprint" to "what is the next most valuable thing to point a loop at, and is the loop ready to run safely." | Old practice | Why it existed | Agentic replacement | |--------------|----------------|---------------------| | Two-week sprints | Batch uncertainty, sync people | Continuous flow of small changes | | Story point estimation | Forecast human capacity | Throughput and loop efficiency metrics | | Daily standup | Surface blockers across people | Live dashboards of loop and pipeline state | | Backlog grooming | Prioritize a scarce team | Intent shaping: writing specs agents can execute | ### What this demands of leadership Running flow instead of sprints means you cannot hide behind a cadence. There is no two-week window in which problems quietly accumulate before a demo. Quality, cost, and direction are visible continuously, and they must be managed continuously. The operating model rewards leaders who can specify intent precisely and decide quickly, and it punishes leaders who need a meeting to make every call. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The most common mistake in 2026 is to staff the new department like the old one and then bolt agents onto the side. The result is a team that uses agents as faster typists while keeping every old handoff intact. The org design has to change with the operating model. Fewer people write code directly. More people direct, review, and own the systems that keep agents safe and productive. ### The roles that matter now | Role | What they own | Why it exists | |------|---------------|---------------| | Loop and orchestration engineer | Designs and tunes the agent loops and the specs that feed them | The loop is the unit of work; someone must engineer it | | Reviewer (senior engineer) | Judges agent output, owns merge decisions and quality bars | Agents produce volume; judgment must scale to match | | Platform owner | Owns the pipeline, guardrails, and the agent runtime | Speed is only safe on a strong platform | | Product translator | Turns business intent into specifications agents can execute | The bottleneck is clarity of intent, not coding | | Security and governance lead | Owns permissions, policy-as-code, audit, and approvals | Autonomy without governance is a liability | ### What disappears, and what grows Roles whose primary value was hand-producing routine code shrink. The work of typing out a standard endpoint, a form, or a migration is now done by an agent in minutes. What grows is everything that requires judgment that agents do not reliably have: deciding what deserves to be built, deciding whether a change is genuinely correct and safe, owning the platform that the agents run on, and translating fuzzy business needs into precise intent. This is not a reduction in skill. It is a shift up the value chain. A senior engineer in this department spends the day reviewing, architecting, and tuning loops rather than producing boilerplate. A new hire is no longer valued for raw output but for the speed at which they can develop the judgment to review and direct. ### A practical staffing ratio A small agentic department can run with a handful of senior people covering these roles, where a traditional team would have needed several times as many builders. The point is not to celebrate a smaller team. It is to staff for review and control capacity, because in an agentic department, your ability to safely absorb agent output is the real constraint, not your ability to produce it. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The delivery pipeline is where an agentic department earns its speed and protects itself from its own velocity. The principle is simple to state and hard to execute: humans belong at the decision gates, not at the keystrokes. Agents do the producing. People decide what to point the agents at and whether to let the result through. ### The pipeline, stage by stage 1. **Intent.** A product translator turns a business need into a precise specification: what should change, what must not change, how success is measured, and what the acceptance criteria are. A vague intent produces a vague change. This stage is where quality is won or lost. 2. **Plan.** The agent proposes a plan before writing code. A human can approve, adjust, or reject the plan cheaply, before any work is done. Catching a wrong approach here costs minutes; catching it after the build costs hours. 3. **Build.** The agent writes the code and the tests together. Tests are not an afterthought; they are part of the deliverable that makes the change reviewable and safe. 4. **Automated review.** Static analysis, security scanning, the test suite, and policy checks run automatically. A second agent can perform a first-pass review, flagging issues before a human spends attention. 5. **Human decision gate.** A senior reviewer makes the merge decision. They are not reading every line as if they typed it; they are judging correctness, risk, and fit, supported by the automated signals. 6. **Production.** The change ships through progressive rollout, watched by observability that can trigger an automatic rollback. ### Where humans must stay | Stage | Who acts | Human role | |-------|----------|------------| | Intent | Human | Author and own the specification | | Plan | Agent proposes, human approves | Decision gate | | Build | Agent | None, by design | | Automated review | Tooling and review agent | None, by design | | Merge | Human | Decision gate | | Production rollout | Automation, human on call | Oversight and override | The discipline is to resist two temptations: the temptation to review nothing because the agent is usually right, and the temptation to review everything line by line because old habits feel safe. Neither scales. The pipeline is designed so that human attention is spent only where judgment changes the outcome. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

In an agentic department, deploying to production every day is not an aspiration. It is the natural consequence of small changes flowing continuously through a trusted pipeline. The question is not whether you can ship daily. It is whether each individual change is small and safe enough that shipping it is unremarkable. ### Why small and frequent beats large and rare Large, infrequent releases concentrate risk. When dozens of changes ship together, a failure is hard to isolate, and the rollback is blunt. Small, frequent changes spread risk thinly. Each change is independently shippable, independently reversible, and easy to attribute when something goes wrong. When agents author most of the code, the cost of producing a small change is trivial, so there is no economic reason to batch. ### The practices that make daily deployment safe - **Trunk-based flow.** Changes are small and integrate into the main line continuously. Long-lived branches accumulate risk and merge pain, both of which defeat the speed agents give you. - **Feature flags.** New behavior ships dark, decoupled from deployment. You deploy code continuously and release functionality deliberately, on your schedule rather than the pipeline's. - **Progressive rollout.** A change reaches a small slice of traffic first, then expands as it proves healthy. The blast radius of any single mistake stays small. - **Automated gates.** The test suite, security scans, and policy checks are the price of admission to production. A change that fails any of them never reaches users. ### The mindset shift | Old assumption | Agentic reality | |----------------|-----------------| | Deployment is a risky event | Deployment is a routine, automated non-event | | Release and deploy are the same | Deploy continuously, release behind flags | | Roll back means emergency | Roll back is a normal, rehearsed action | | Fewer releases are safer | Smaller, more frequent releases are safer | Daily deployment is not reckless when it rides on small changes, strong gates, and instant rollback. It is reckless only when those foundations are missing. The job of the platform team is to make shipping so safe and so ordinary that the question of "should we deploy today" stops being asked at all. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The fear that stops most executives from embracing agentic delivery is loss of control. The instinct is to add human checkpoints everywhere, which restores the feeling of control while destroying the speed that justified the model. The art is to build control into the system itself, so that safety does not depend on a person standing in the way of every change. ### Policy as code The most important shift is to express your rules as code that runs automatically, not as guidelines that people are expected to remember. If a change must not touch the payments path without an extra approval, that rule lives in the pipeline and enforces itself. If certain data must never leave a region, the policy blocks any change that would violate it. Policy-as-code turns control from a meeting into a property of the system. ### Where a human sign-off is mandatory Not everything should be automatic. The skill is in choosing the few gates that genuinely require human judgment and automating everything else. | Change type | Control mechanism | |-------------|-------------------| | Routine change, well covered by tests | Automated gates only | | Change to a high-risk path (auth, payments, data deletion) | Mandatory senior human approval | | Schema or data migration | Human approval plus a tested rollback plan | | New external dependency | Security review and human approval | | Change to the guardrails themselves | Two-person approval, always | ### Guardrails that scale with volume Because agents produce far more changes than a human-only team, the controls must scale without adding people. Automated review gates, a comprehensive test suite, security scanning on every change, and policy-as-code all scale at the speed of compute, not the speed of hiring. The human gates are reserved for the small fraction of changes where the stakes are high enough that judgment is worth the wait. The result is a department that is more controlled than a traditional one, not less. Every change is tested, scanned, policy-checked, and attributable. The control is simply enforced by the system instead of by a bottleneck, which means it holds even as volume rises. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The greatest long-term risk in an agentic department is not a bad deployment. It is the slow accumulation of code that works today but that no one understands, owns, or can safely change tomorrow. Agents can produce volume effortlessly, and volume without discipline becomes sprawl. Maintainability is not a phase that happens after building. It is a constraint that the building process must respect on every change. ### The sprawl problem When producing code is nearly free, the temptation is to solve every problem by generating more of it. Duplicated logic, slightly different versions of the same utility, dependencies added casually, and abstractions invented for a single use all pile up. None of it looks dangerous individually. Together it becomes a codebase that is expensive to reason about and risky to change, which quietly erases the speed advantage that agents were supposed to provide. ### The disciplines that hold it back - **Clear ownership.** Every part of the system has a named human owner who is accountable for its health, even though agents do most of the editing. Ownership without an owner is sprawl waiting to happen. - **Tests as a first-class deliverable.** A change is not complete until it carries tests that make the next change safe. Tests are what let the next agent edit confidently. - **Documentation as output.** Agents should produce the explanation alongside the code: why the change was made, what it affects, and how to undo it. This costs the agent almost nothing and saves the humans enormously. - **Refactoring loops.** Schedule loops whose only job is to reduce duplication, simplify, and remove dead code. In an agentic department, refactoring is cheap, so neglecting it is inexcusable. - **Dependency hygiene.** New dependencies require justification and review. Every dependency is a long-term liability that an agent will not feel but the department will. ### Maintainability as a metric, not a virtue | Signal | What it tells you | |--------|-------------------| | Duplication rate | Whether agents are reinventing instead of reusing | | Test coverage on changed code | Whether new work is safe to build on | | Dependency count and age | Whether the surface area is growing unchecked | | Time for a new owner to understand a module | Whether the system is still legible | Treat these as operational metrics that you watch continuously. Maintainability that is left to good intentions will lose to the sheer volume an agent fleet produces. Maintainability that is measured and enforced is what lets the department stay fast for years rather than months. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

When changes ship daily and agents author most of them, you cannot rely on memory or tribal knowledge to know what is running in production. You need to know, at any moment, exactly what was shipped, by which loop, on whose approval, and how to undo it safely. Observability and rollback are what make high-speed delivery survivable. ### Observability for an agentic system Traditional monitoring tells you that the system is healthy or not. An agentic department needs more: it needs to connect every production behavior back to the change that caused it and the agent and human who produced it. That means rich telemetry on the running system, and an unbroken trail from a symptom in production to the exact change, plan, and approval behind it. | Layer | What you observe | Why it matters | |-------|------------------|----------------| | Runtime | Errors, latency, traffic, resource use | Detect problems fast | | Change | Which change altered which behavior | Attribute problems to causes | | Agent action | What the agent did and why | Audit and improve the loops | | Decision | Who approved what, and on what evidence | Accountability and learning | ### Rollback as a routine In a daily-deployment department, rollback is not an emergency procedure pulled out once a year. It is a normal, rehearsed action that any on-call engineer can take with confidence. Because changes are small and independently shippable, rolling one back rarely means undoing unrelated work. Feature flags allow you to disable a behavior instantly without even redeploying. Progressive rollout means most problems are caught while exposed to a small slice of traffic, before they reach everyone. ### Audit trails for agent actions Every action an agent takes should be logged in a way that a human can later reconstruct: the intent it was given, the plan it proposed, the code it produced, the checks that ran, and the human who approved the result. This is not bureaucracy. It is what lets you trust an automated system: when something goes wrong, you can see exactly how it happened, fix the loop, and prevent the whole class of problem rather than patching a single instance. The combination of deep observability and routine rollback is what turns speed from a liability into an asset. You can move fast precisely because you can see everything and undo anything. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

An agent that can write and ship code is, in security terms, a powerful actor inside your systems. Treating it casually is the fastest way to turn an efficiency gain into a breach. The governing principle is least privilege: every agent gets exactly the access it needs to do its task and nothing more, and every powerful action passes through a control that a human or a policy owns. ### Permissions and secrets Agents should never hold standing access to everything. They should receive narrowly scoped, time-limited credentials for the specific task at hand. Secrets must never be embedded in code or prompts; they must be injected at runtime through a managed secrets system and never logged. An agent that needs to touch production data does so through an audited, permissioned path, not through a general-purpose key that would let it do anything. | Risk | Least-privilege control | |------|-------------------------| | Over-broad access | Task-scoped, time-limited credentials | | Secret leakage | Managed secrets, injected at runtime, never logged | | Unreviewed production access | Audited, permissioned data paths only | | Privilege creep | Regular access review and automatic expiry | ### Governance and approvals Governance is the set of rules that decide what is allowed, who can approve exceptions, and how it is all recorded. In an agentic department, governance is most effective when it is expressed as policy-as-code so it enforces itself, backed by human approval for the small number of high-stakes decisions. Compliance requirements, whether regulatory or internal, become checks in the pipeline rather than documents that people are asked to honor. ### Designing agents to be safe by default - Give each agent the minimum scope for its loop, and expire it when the loop ends. - Require human approval for any action that touches a high-risk path. - Keep an immutable audit trail of every agent action and every approval. - Treat the guardrails as critical infrastructure: changes to them require the strongest controls you have. Security and governance are not the brakes on an agentic department. They are what make it safe to press the accelerator. A department that gets this right can give agents real autonomy precisely because the boundaries of that autonomy are enforced, recorded, and reviewable. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The metrics that governed traditional IT, story points completed, utilization, lines of code, are worse than useless in an agentic department. When an agent can produce code at will, output volume measures nothing. The metrics that matter measure flow, quality, and control: how fast value moves, how often it breaks, and how quickly you recover. ### The core set | Metric | What it measures | Why it matters | |--------|------------------|----------------| | Throughput | Changes shipped to production per period | The real velocity of the department | | Escaped-defect rate | Defects that reach production per change | Whether speed is costing you quality | | Loop efficiency | Share of loops that succeed without human rework | How well your loops are engineered | | Cost per change | Total cost (compute plus oversight) per shipped change | The true economics of the model | | Mean time to rollback | How long to safely undo a bad change | Your real safety margin at speed | ### How to read them together No single number tells the truth. High throughput with a rising escaped-defect rate means you are shipping faster than you can safely review, and you should tighten gates or slow down. High loop efficiency means your specifications and checks are well designed, and you can safely point agents at more ambitious work. A rising cost per change means your loops are doing too much rework, which usually traces back to vague intent at the specification stage. ### What to stop measuring Stop counting output as if it were value. An agent fleet can generate unlimited code, so lines of code, commits, and tickets closed measure activity, not progress. Stop measuring individual human productivity by volume; the senior people in this department add value through judgment, and judgment does not show up in a commit count. Measure the system, not the typing. The discipline of good metrics is what keeps an agentic department honest with itself. Speed without an escaped-defect rate is bragging. Throughput without cost per change is a hidden budget problem. The right handful of metrics, watched continuously, is how you prove that you are fast and safe at the same time, rather than just fast. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

Standing up an agentic IT department from zero is a sequencing problem. Build the platform and the controls before you scale the volume, or the speed will outrun your ability to stay safe. The following is a concrete ninety-day sequence that puts foundations first and earns trust before it scales. ### Days 1 to 30: Foundations The first month is about the platform and the people, not about shipping features. Hire or assign the small senior core: a platform owner, one or two reviewers, a loop engineer, and a security and governance lead. Stand up the delivery pipeline with automated gates from day one: tests, security scanning, and policy-as-code. Establish the agent runtime with least-privilege access and managed secrets. Wire up observability and a rehearsed rollback before any agent touches anything that matters. ### Days 31 to 60: First loops In the second month, run real but low-risk work through the pipeline. Pick changes that are genuinely useful but where a mistake is cheap. Let the team learn to write specifications agents can execute, to review agent output efficiently, and to tune the loops. The goal is not volume yet. It is a trustworthy loop: one where a well-specified intent reliably produces a safe, shippable change with minimal rework. Measure loop efficiency and escaped-defect rate from the first day so you are improving against real numbers. ### Days 61 to 90: Scale with control Only once the loop is trustworthy do you scale volume. Add more loops, point them at more ambitious work, and let daily deployment become the norm. As volume rises, lean harder on policy-as-code and automated gates so that control scales with compute rather than with headcount. Introduce mandatory human gates on the high-risk paths and automate everything else. By the end of ninety days, the department should be shipping small changes to production routinely, with every change tested, scanned, attributable, and reversible. | Phase | Focus | Done looks like | |-------|-------|-----------------| | Days 1 to 30 | Platform and controls | Pipeline, guardrails, observability, rollback all live | | Days 31 to 60 | First trustworthy loop | Specs to safe changes with low rework, measured | | Days 61 to 90 | Scale with control | Daily deployment, control enforced by the system | The order is the lesson. Foundations, then trust, then scale. Reverse it, and you will spend the time you saved cleaning up what you shipped too fast. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*

The new shape of an IT department is a controlled-yet-autonomous engine room. Agents do most of the producing. A small group of senior people set the direction, guard the gates, and own the platform. The system ships to production almost daily, almost entirely automatically, and yet it is more controlled, more observable, and more reversible than the slow departments it replaces. The two failure modes are easy to name. The first is timidity: building the new department like the old one, adding agents as faster typists while keeping every handoff and every meeting, and capturing none of the speed. The second is recklessness: pointing agents at production with no gates, no policy-as-code, no observability, and discovering too late that fast and unsafe is worse than slow. The whole discipline lives in refusing both. What makes the middle path possible is a single idea repeated at every layer: put humans at the decisions, not the keystrokes. Humans author intent, approve plans, guard the high-risk gates, and own the systems. Agents do the rest, fast and continuously, inside boundaries that are enforced by code rather than by bottlenecks. Control stops being a person standing in the way and becomes a property of the system itself, which is the only kind of control that survives at speed. The executive who builds this well will run a department that is smaller, faster, and safer than anything the previous era allowed. The advantage is real and it compounds: every well-engineered loop makes the next change cheaper, every guardrail makes the next deployment safer, and every honest metric keeps the whole machine pointed at value rather than mere motion. The engine room of an AI-native company is not a crowd of people typing. It is a small, senior crew running a fleet of agents through a pipeline they trust, shipping to production by default, and sleeping at night because the controls hold. That is the department worth building in June 2026, and it is within reach of any leader willing to put foundations before speed and judgment before volume. --- *Part 29 of the Running the AI-Company Series* *A field guide from the Running-ai team of experts, June 2026*