Category Archives: Enterprise Technology

From Automating Tasks to Delegating Intent

by

0


The next abstraction layer: machines no longer execute only our steps. They begin to execute our intent.*

In various discussions with CIOs and platform teams over the last months, I keep hearing the same concern: we automated almost everything, and still we are drowning in operational work. More pipelines. More scripts. More dashboards. More tickets generated by the systems that were supposed to remove tickets.

How can that be?

Because automation was never the destination. It was the first step of a much longer journey. For more than a decade, we taught machines to repeat what we do. Agentic AI now introduces a different contract: the machine does not only repeat a task. It interprets an objective, decides between possible actions, and adapts when reality does not follow the expected path.

This sounds like a technical evolution. I believe it is mainly a leadership evolution.

Did automation solve the problem?

Automation solved an important class of problems. Infrastructure as Code made environments reproducible. CI/CD removed many manual handovers. Policy engines, secret rotation, autoscaling and observability moved operational work from documents into systems. This was a great achievement.

But traditional automation has a hard boundary. It executes the procedure we already know. A script does exactly what you wrote, at machine speed, including your mistakes. When the environment changes, the exception moves back to a human. When two policies conflict, the workflow stops. When the goal is clear but the path is not, the ticket lands again in the platform team.

We automated the known path and created specialists for everything outside the path. The result is a strange paradox: highly automated organizations can still require enormous coordination. The machine handles the steps, while humans spend their time connecting the steps, interpreting exceptions and deciding what should happen next.

The bottleneck moved. It did not disappear.

What has changed?

Agentic AI raises the abstraction level from task to intent. Instead of saying, “run this pipeline, apply this configuration and restart that node,” we can formulate an outcome: keep this service compliant, keep its cost inside an agreed corridor, and remediate drift before it becomes an incident.

The difference is fundamental. A task describes the how. Intent describes the what and the why, together with the boundaries that must not be crossed.

History offers a useful analogy: mission command. In the nineteenth century, military organizations discovered that detailed orders collapse the moment reality disagrees with the plan. Communication was slow, conditions changed, and the person closest to the situation often had better information than the commander far away. The answer was not less discipline. It was a different form of discipline: communicate a clear objective, define constraints, and allow trained officers to decide the execution on the ground.

You have seen both models in your own career. Micromanagement is task-based. The manager prescribes every step, checks every result and becomes the bottleneck of the team. Leadership is intent-based. The leader defines the objective and the boundaries, then trusts people to find the path.

For a decade we micromanaged our machines. Agentic AI asks us to lead them.

Autonomy without boundaries is not delegation. It is uncontrolled execution.

Where is the catch?

The catch is that delegation only works on a disciplined foundation. An officer without doctrine is not empowered; he is dangerous. The same is true for an autonomous agent operating on enterprise infrastructure.

Three foundations are non-negotiable.

First, the agent needs a declarative source of truth. It must know the desired state, not only the current state. Architecture decisions, service ownership, compliance requirements and operational limits cannot remain distributed across outdated wiki pages and the memory of a few senior engineers.

Second, every action needs identity. An agent should never inherit a broad technical account simply because this is convenient. Human and machine actions must be authenticated, scoped and traceable. If an autonomous system can change production, we need to know which identity acted, against which objective, with which permissions and based on which context.

Third, constraints must become executable. A statement such as “do not create unnecessary risk” is good leadership language but bad machine policy. The boundary has to be explicit: which environments may be changed, which cost threshold applies, which data is sensitive, which action requires approval, and when the agent must stop.

Without these foundations, we are not delegating intent. We are automating chaos at a higher level of abstraction.

Can responsibility be delegated as well?

This is the question I feel most strongly about. Mission command never removed the commander’s accountability. It sharpened it. The officer decides on the ground, but the commander owns the outcome.

The same principle must apply to AI agents. A system can plan, execute, evaluate results and change its approach. It can operate faster and across more information than any individual. But it cannot be responsible. Responsibility is not a workload we can schedule, and accountability is not metadata we attach after an incident.

This also changes the role of platform teams. Their value moves away from processing every operational task and toward designing the environment in which decisions can safely be delegated. They become authors of intent, boundaries and escalation paths. They define the operating model for human and machine actors together.

That is not less engineering. It is engineering one abstraction layer higher.

Where should CIOs start?

Do not start with the agent. Start with the intent.

Most organizations I talk to cannot describe on one page what “good” looks like for their infrastructure. Which risks are acceptable? Which costs are tolerable? Which changes need a human decision? Which business outcome has priority when reliability, speed and cost conflict?

If you cannot express the intent clearly to a colleague, you cannot delegate it to a machine.

My advice to CIOs is simple: treat the next two years as officer training for your platform. Select low-risk operational domains where the outcome is measurable. Write down the objective and the constraints. Give the agent only the identity and authority it needs. Observe every decision. Improve the doctrine before you expand the autonomy.

Do not measure success only by tasks eliminated. Measure how many decisions can be made safely without coordination overhead, how often the system escalates correctly, and whether humans can still explain why an action happened.

The journey from automation to delegation is not primarily about smarter machines. It is about clearer organizations. The quality of the outcome will depend on the quality of the intent, the discipline of the guardrails and the willingness of leaders to remain accountable.

The machine can execute the mission. You remain the commander.

Written by human, curated by AI, pictures by OpenAI

The Quiet Rewiring: How Advanced AI Systems Are Reshaping the Fabric of Enterprise IT

by

0


Over the last three years, something fundamental has shifted beneath the surface of enterprise technology. It did not arrive with a press release or a migration deadline. It came through the daily work of developers, platform engineers, and IT specialists who started to notice that their tools had become collaborators. After thirty-five years in this industry, from mainframes through client-server, from virtualization through cloud-native, I can say with some confidence: this shift is different. Not because the technology is louder, but because it is quieter and deeper than anything before.

From Writing Code to Owning the Lifecycle

For decades, the developer’s identity was built around writing code. Good code. Clean code. Clever code. But the role has been expanding for a while now, and large frontier models have accelerated that expansion dramatically. Today, a developer who only writes code is already behind. The expectation has moved toward lifecycle ownership — from initial design through deployment, observability, and incident response.

I remember when we introduced CI/CD pipelines in our organization around 2015. It took almost two years before the development teams truly owned them. Now, advanced coding systems from major AI labs generate not just the application logic but also the pipeline definitions, the infrastructure-as-code templates, and the test scaffolding. The developer’s job is no longer to produce all of this. It is to understand, validate, and take responsibility for it.

This is a cultural shift, not a tooling upgrade. And it puts enormous learning pressure on people who were already stretched thin.

AI as a Reasoning Partner, Not a Magic Box

State-of-the-art foundation models today can refactor legacy code, generate comprehensive test suites, produce documentation that is actually readable, and suggest architectural patterns that would have taken a senior engineer hours to draft. I have seen this firsthand — a platform team in one of my previous engagements reduced their infrastructure documentation backlog by seventy percent in three months, using new generation reasoning systems as their drafting partner.

But here is the part that gets lost in the excitement: these systems do not understand your business context. They do not know why that particular microservice has a strange retry logic that was added after a production incident in 2019. They do not carry the institutional memory. The risk of over-reliance is real and already visible. I have reviewed pull requests where the generated code was syntactically perfect and architecturally wrong. The skill that matters now is not prompting. It is critical reasoning, validation, and the ability to say “this looks correct but it is not right for us.”

AI amplifies capability. It does not replace responsibility.

Prompt Engineering Dies — System Design Lives

There was a brief period, maybe eighteen months, where everyone talked about prompt engineering as if it were a new discipline. People wrote courses about it, built careers around it. I was skeptical then, and the trajectory has proven that skepticism right. The single-prompt optimization is becoming irrelevant at a speed that should concern anyone who invested heavily in that narrow skill.

What replaces it is far more interesting and far more demanding. Multi-agent orchestration, workflow design, memory architectures, context management across complex reasoning chains — this is system design, not prompt crafting. The prompt engineer is becoming the AI system architect, and that requires a fundamentally different skillset. You need to understand how state flows through distributed reasoning processes, how to design fallback strategies when one agent produces unreliable output, and how to build guardrails that are structural rather than textual.

In my own work, I have moved from asking “how do I phrase this better” to asking “how do I design this workflow so that the output is reliable regardless of how each individual step performs.” That is an engineering mindset, not a linguistics exercise.

The Enterprise Beyond Applications

Something else is happening in the enterprise that deserves attention. The traditional model of building or buying applications for every business function is dissolving. In its place, AI agents and intelligent workflows are emerging — , Software Development Lifecycleot as fancy automation scripts, but as genuine decision-support systems that operate on massive amounts of data that no human team could process manually.

I spent years in organizations where middle management existed primarily to aggregate information from below and pass summarized decisions upward. Large frontier models are compressing that chain. Not by eliminating people, but by removing the friction of information synthesis. A security operations team that used to spend four hours triaging alerts before making a decision can now have an AI agent pre-analyze, correlate, and present a recommended action path within minutes. The human still decides. But the human decides faster and with better data.

Less management overhead. More focus on the core of the task at hand. This is not a slogan — it is what I am observing in real organizations right now.

The Psychological Weight of Constant Adaptation

What I do not see discussed enough is the psychological impact on the people living through this transformation. Every six months, the capabilities of advanced reasoning systems take another leap. Every six months, the baseline expectation for what a single engineer should be able to deliver shifts upward. This is exhausting. I know because I feel it myself, and I have been adapting to technology shifts for three and a half decades.

The pressure to continuously learn, to re-evaluate what you thought was a stable skill, to accept that your hard-won expertise in a specific area might be commoditized within a year — this is not trivial. Organizations that ignore this human dimension while chasing productivity gains from AI will find themselves with burned-out teams and high attrition. The technology is only as good as the people who guide it, and those people need support, time, and psychological safety to adapt.

So What Changes for People?

Everything and nothing. The fundamental truth of enterprise IT remains: humans build systems for other humans, and someone must be accountable when things go wrong. What changes is the layer between intention and execution. That layer is now filled with powerful reasoning systems that can draft, suggest, generate, and analyze at a scale we never had before.

For developers, the path forward is clear: become the person who understands why, not just how. For platform engineers, it means designing systems where AI agents and human operators work in well-defined boundaries. For security engineers, it means building Zero Trust not just for networks but for AI-generated outputs. And for IT leaders, it means accepting that the most important investment right now is not in technology. It is in the people who must learn to work alongside it.

After thirty-five years, I have learned that technology always promises more than it delivers in the short term, and delivers more than we imagined in the long term. The frontier models we see today are no exception. But the transition — the human transition — that is where the real work happens. And that work is happening right now, in every team, in every organization, whether we acknowledge it or not.