The Engineer Becomes the Agent Manager: My Techstrong TV Interview

Making my first appearance on Techstrong TV meant a great deal to me. Alan Shimel and I talked about the journey from working in an aluminum factory to network engineering and my role at Itential. We also explored an idea I raised in the interview, attributed to Jensen Huang: IT becoming an HR department for AI agents.

That is a provocative way to describe an engineering problem. Once agents participate in operations, somebody has to decide how their work fits together and take responsibility for what the team delivers.

The interview, IT Is Becoming an HR Department for AI Agents, was published on November 3, 2026. Watch the conversation and read the transcript on Techstrong TV.

Here is how I would put that idea to work, and why I think experienced engineers have so much to contribute.

Give the agent a job somebody can evaluate

“Help with the network” is a difficult assignment to manage. Where does the work begin? What would make it complete? Which problems belong to another team?

Consider a more useful assignment: review the access switches at one branch before its maintenance window and produce a list of interfaces that need an engineer's attention. The agent should identify the devices it examined, explain each finding, and distinguish an observed fault from information it could not retrieve.

That assignment has a customer, a scope, and an output someone can inspect. It also creates room for an honest answer: two switches were unreachable, so the branch review is incomplete.

Before adding an agent to the team, I want a short role description that answers five questions:

1. Who uses its output? Name the person or next stage that needs the work.
2. What is it responsible for? Describe an outcome small enough to evaluate.
3. What is outside its authority? Make the boundary understandable to an operator.
4. When should it ask for help? Define conditions that require another decision.
5. Who maintains it? Identify the owner when a tool, requirement, or dependency changes.

Writing those answers forces useful conversations before the first production run. It also gives the team a basis for deciding whether the agent is earning its place.

The handoff deserves as much design as the agent

A group of capable agents can still produce a confused operation. The gaps between responsibilities are where work gets lost.

Imagine an investigation that hands a proposed change to another component. What travels with that proposal? A paragraph saying the branch looks healthy is difficult to audit. A record containing device identities, collection times, unresolved findings, and links to the observations gives the next stage something concrete to examine.

I would design the handoffs before making the system more autonomous:

Handoff	What the receiving stage should have
Request to investigation	A named service, affected location, requested outcome, and limits on the investigation
Investigation to proposal	Observations tied to specific devices, collection times, and unresolved questions
Proposal to review	The proposed scope, expected impact, alternatives considered, and reasons to stop
Review to execution	An identifiable approved version and the exact target environment
Execution to verification	A record of attempted operations, their responses, and any uncertain outcomes
Verification to the operator	Evidence against the original request, remaining work, and a clear owner for follow-up

This is an example design, not a requirement to create six separate agents. Some stages may be ordinary automation. Some may be performed by a person. Add a separate agent when its responsibility and contribution justify the extra moving part.

The important question at every boundary is whether the next participant has enough information to do its job without guessing what the previous one meant.

Permission is an engineering decision

The management analogy becomes useful when it reaches the system's actual controls. A role description tells us what an agent should do. Its operating environment determines what it can do.

In my DevOps.com article about engineering an agent's operating environment, I make the case for putting permissions, approvals, current context, and completion evidence around the model. Mandatory controls need an enforcement point in the execution system. A written instruction to obtain approval cannot provide that enforcement by itself.

For the branch example, I would ask the team to demonstrate an attempted operation outside the assigned scope. Show what happens when the review agent tries to change a switch. Show what happens when an approval refers to an older revision of the proposal. Show the operator what was denied and why.

Those demonstrations make a design review much more productive. We can examine observable behavior and decide whether it matches the responsibility we intended to delegate.

Evaluate the reviewer, too

An agent reviewing another agent's work creates a second place where assumptions need testing. Agreement between two components is useful only when we understand what each examined.

My Jev and FlowAgents walkthrough gives this discussion a concrete reference. Jev assessed evidence and outcomes while other models handled coordination and execution. One run led to a rollback request and an incomplete recovery that needed operator attention. I kept that sequence in the demonstration. The article also documents successful lab runs, including a mode with human approval.

For a reviewer, I would build an evaluation set containing plausible proposals with deliberate problems: a missing dependency, an unsupported device, a change that exceeds the request, or a recovery procedure that relies on access the change could remove. Include good proposals too. A reviewer that rejects everything is not doing the job either.

Measure whether it identifies the specific problem, asks for the missing evidence, and sends the work to the right next step. Keep examples of both incorrect acceptance and unnecessary rejection. Review those examples with the engineers who understand the service.

A numerical assessment can help organize that review. Its practical value comes from how well it performs on cases the team can judge. A precise-looking number should never end the engineering conversation.

Manage the cost of completed work

The useful budgeting unit is an accepted result. For the branch review, that means an accurate report the engineer can use before the maintenance window.

Record the model usage, tool calls, elapsed time, and human review time required to produce that result. Include retries and corrections. If a cheaper configuration generates reports that take twenty minutes to repair, the apparent saving may disappear. If a more capable configuration adds expense without improving acceptance, that matters too.

Run a representative set of assignments before changing the team-wide default. Compare the results against the same criteria. Keep enough detail to understand whether an improvement came from a different model, a clearer assignment, better input data, or a repaired tool.

That gives the agent manager a practical way to make purchasing and configuration decisions. It also helps explain the value of the work to people who care about service delivery more than model benchmarks.

An agent needs an owner after launch

Onboarding is only the beginning of the management job. An agent can accumulate permissions, scheduled work, and downstream dependencies over time. Somebody needs to know which of those remain necessary.

I would keep a simple service record for each operational agent: its owner, purpose, authorized environments, consumers, evaluation results, and review date. When its responsibilities change, review the permissions with them. When it is retired, remove its access, stop its schedules, and tell the people who depended on its output where that work has gone.

There is a capacity question as well. If ten agents all escalate to one engineer at the same moment, the system has created a queue that someone must manage. Define priorities and a useful escalation format. An urgent request should tell the operator what happened, what is waiting, and what decision is needed.

These details deserve a place in the design because they determine whether people can actually operate the system on a busy day.

Experience belongs in the design

The engineer who knows which dependency is absent from the diagram has something valuable to contribute. So does the operator who knows why a particular maintenance procedure includes an apparently unnecessary pause. Turning that knowledge into clear assignments, evaluation cases, and escalation rules is substantial technical work.

For someone entering the field, there is a useful way to practice: choose a small lab task, write down the expected result, and review an agent's attempt. Investigate the differences. Learn the underlying network behavior well enough to explain why the result is acceptable or incomplete.

For an experienced engineer, try the same exercise with a task you already understand deeply. Your familiarity with its awkward cases is an advantage. Those cases will teach you far more about the system than a perfect demonstration alone.

This is the opportunity I want to explore: engineering teams that can delegate more work while remaining able to explain, evaluate, and own the result. Building that capability takes judgment. It gives the experience already inside our teams another place to make a difference.

Thank you to Alan and Techstrong TV for the conversation and the welcome. I am proud to have this milestone here.

• Watch the full interview on Techstrong TV.
• Explore my work at Itential and the Lumen workshop photos and reflections.
• Keep learning through NetClaw, MCP, and VibeOps.

The interview was published November 3, 2026. This accompanying article was published November 5 and expands on the conversation with practical design examples.