Claude and OpenAI are bringing what feels like a real storm to IT. I don’t expect that storm to hit every kind of work equally.
My view is that work reducible to “given clear intent, produce correct code” will face increasing automation. That includes tasks across experience levels. The question for us is how we grow beyond producing code to taking responsibility for the systems that code creates.
Writing an implementation is one part of engineering. Understanding the problem, deciding what should happen, anticipating what could go wrong, and verifying the outcome are equally essential.
With AI agents, those responsibilities become especially visible.
A capable model still needs a dependable system around it
An agent may understand a request, select a tool, and execute an action. But can we trust it to choose the right action, use the right information, respect the right boundaries, and recognize when it should stop?
That is where harness and loop engineering matter.
Harness engineering shapes the environment the agent operates within: its instructions, tools, context, memory, permissions, approval gates, execution limits, and observability.
Loop engineering shapes how execution progresses: the model chooses an action, the system executes it, results return, and the agent decides whether to continue, recover, ask for help, or finish.
The harness provides the controls and resources. The loop turns the goal into successive actions within those controls.
Neither becomes dependable simply because the underlying model becomes more capable.
A successful tool call is only part of the story
Consider an agent asked to update an enterprise record through a tool exposed by an MCP server.
The tool executes and reports success. That tells us something about the operation—but it doesn’t establish that the agent selected the correct record, made the intended change, or acted with the required business approval.
The tool could work exactly as designed while the overall task still fails.
“Tool-call success is not task success in the agentic AI world.”
We need to verify the outcome against the original intent. Was the correct record updated? Were the values correct? Were permissions and approval requirements enforced? Can we trace the decision and recover if something went wrong?
Authorization must be enforced by the system. It cannot depend on the model remembering to behave.
Engineering includes recognizing quiet failures
Some failures are obvious: a tool times out, a connection fails, or an exception appears.
Others are harder to detect. An agent uses outdated context, selects a similarly named record, treats incomplete evidence as sufficient, or declares completion before checking the result.
The workflow finishes. The answer sounds confident. The business outcome is still wrong.
This is why evaluations, monitoring, and human escalation belong in the design from the beginning. We need evidence that the system performs acceptably, including when information is missing, requests are ambiguous, or tools fail.
Confidence is not correctness. Completion is not proof.
The frameworks will change. Judgment must keep growing.
Learning MCP, A2A, Agent Skills, and evaluation frameworks is useful. But no particular protocol or framework is a permanent career advantage.
Implementation patterns will evolve. Some work we perform manually today may become a standard platform feature tomorrow.
The more durable skill is engineering judgment: understanding the domain, identifying failure modes, choosing appropriate controls, and knowing what evidence is sufficient to trust an outcome.
That judgment includes deciding when an agent is appropriate at all. Some tasks are better served by a deterministic workflow. Others need an agent with constrained autonomy. Some decisions require human review.
Good engineering means making that choice deliberately.
Business value remains the goal
An agent taking more steps or using more tools is not automatically delivering more value.
We should ask whether it improves quality, reduces turnaround time, controls cost, and earns users’ trust. We should also know who owns the outcome when it makes a mistake.
Greater autonomy should come with clear accountability and verification proportionate to the consequences.
For me, this is the opportunity ahead: combining software fundamentals, domain knowledge, and a reliability mindset with the ability to build and evaluate AI systems.
No skill guarantees that we will remain unaffected by change. But learning to take responsibility for the whole system gives us a stronger foundation for adapting.
Don’t just learn to code with an agent. Learn to engineer the agent and keep re-engineering your understanding of what that requires.
As agents take on more responsibility in our work, where should we strengthen our engineering practices first?
Thanks
Sreeni Ramadorai
Top comments (0)