The Rise of the Agents: When Software Starts Acting

Software used to wait for you. You opened an application, clicked buttons, filled in forms, and told it exactly what to do. That era is ending. A new class of AI systems doesn't wait for instructions mid-task. It takes a goal, breaks it into steps, picks up tools, executes, checks the result, and adjusts. It acts. If the chatbot were a search bar with manners and the copilot were a keen assistant looking over your shoulder, the agent is something else entirely: a system that operates with a degree of autonomy we previously reserved for people.

Let's just let that sink in!

Because the shift from "tool I use" to "system that acts on my behalf" is not incremental. It changes the trust model, the security model, and eventually the shape of software itself. Anyone who has watched The Matrix will recognise the unease. Agent Smith didn't just answer questions. He pursued neo objectives, replicated and adapted them, and was extremely difficult to put back in the box.

We are not building Agent Smith. But we are building systems that share a few of his more interesting properties: goal-directed behaviour, tool use, and the capacity to chain actions without asking permission at every step.

What agents actually are

The term "agentic AI" is used so loosely as to be almost useless. So let's be precise.

A chatbot responds to a prompt. You ask; it answers. The conversation resets. A copilot sits alongside you in a workflow, suggesting code completions, summarising documents, and drafting emails. It augments, but you remain the driver.

An agent is different in kind. You give it an objective, and it plans a route to get there. It selects and calls tools. It holds the state across steps. It evaluates whether its actions worked and course-corrects if they didn't. The loop is: reason, act, observe, repeat.

The minimum ingredients:

• A goal defined in natural language or structured intent.
• Tools and actions it can invoke: APIs, databases, shell commands, browser sessions, and other models.
• Memory or state that persists across steps, so it doesn't forget what it's already done.
• Planning to decompose a goal into a sequence of sub-tasks.
• Execution to actually carry out those sub-tasks.
• Feedback to evaluate outcomes and decide whether to retry, escalate, or stop.

Strip any one of those out, and you are back to a chatbot with delusions of grandeur.

What this looks like in practice

Definitions are fine. But agents only make sense when you can understand use cases:

The SOC analyst who never sleeps. A security operations centre receives 4,000 alerts on a busy day. An agent ingests the alert feed, clusters related events by asset and time window, enriches indicators against threat intelligence, drafts a triage summary, opens a ticket in the case management platform, suggests containment actions, and queues the package for a human analyst to approve or reject. The analyst still makes the call. But the 45 minutes of copy-paste and tab-switching per incident shrinks to a two-minute review. The hand-off gate is the critical design choice: the agent proposes, the human disposes.

The cloud cost controller. A FinOps team wants to cut waste across 200 AWS accounts. An agent scans resource utilisation data, identifies idle load balancers, orphaned EBS volumes, and oversized instances. It drafts pull requests to resize or terminate, creates change requests in ServiceNow with attached rollback plans, and tags each action with projected monthly savings. No change can be executed without an approved change request. The agent does the legwork; governance stays human.

Procurement from intent to outcome. A hiring manager needs 50 laptops for a new team. They type the request into a chat interface. An agent checks the approved hardware catalogue, confirms budget against the cost centre, generates a purchase order, routes it for approval, and tracks delivery. What used to be six emails, two spreadsheets, and a week of waiting becomes a supervised pipeline that completes in hours. The manager never opens the procurement portal.

In each case, the pattern is the same: the agent handles the operational drudgery while humans hold the decision gates.

Three futures, not one

Predicting the future of software with confidence is a fool's errand; applications are not yet dead. However, we can sketch three plausible trajectories and be honest about the trade-offs.

Coexistence. SaaS platforms and bespoke applications survive largely intact. Agents sit on top as an orchestration layer, calling existing APIs and scraping screens when APIs don't exist. This is the lowest-disruption path and the most likely near-term reality. The downside: you inherit every integration headache you already have, plus one more.

Agent-first. Workflows become intent-driven. Users express what they want; agents figure out how. UIs thin out dramatically. Applications become toolkits, exposing capabilities rather than screens. This is elegant in theory but brutal in practice. It assumes reliable tool descriptions, stable APIs, and a level of trust in autonomous execution that most regulated industries will not grant lightly.

High-assurance split. Safety-critical, regulated, and national-security systems resist agentification. They double down on determinism, formal verification, audit trails, and human-in-the-loop controls. Meanwhile, internal operations, back-office workflows, and developer tooling go fully agentic. You end up with two tiers of software: one fast and fluid, the other slow and secure. This feels the most realistic at scale.

The honest answer is probably all three at once, in different parts of the same organisation.

Will bespoke software still exist?

Yes. But less of it.

Bespoke remains essential where compliance demands precise, auditable logic. Latency tolerances are measured in microseconds. Where deterministic behaviour is a regulatory requirement, not a preference. Where liability is clear and contractual. And where integration complexity is so gnarly that only purpose-built code can hold the seams together.

Where bespoke shrinks is in "glue" code, internal dashboards, repetitive workflow automation, and the vast ocean of "we built a crud app because nobody made the right SaaS tool" software. Agents eat that layer first, because it was never defensible engineering. It was coping.

The new UI and the new operating model

If agents handle execution, what do humans do?

They supervise. They set policies, define guardrails, approve escalations, and monitor outcomes. The interface shifts from "click through 14 screens to complete a process" to "review a summary, approve or reject, move on." Fewer dashboards. More orchestration surfaces. A simple analogy is air traffic control: you are not flying the planes, but you are responsible for making sure they don't collide.

This changes job descriptions. It changes how teams are structured, and it demands a new literacy: understanding what the agent can and cannot be trusted to do, and where the human checkpoint must sit.

Security and risk

Here is where the conversation gets serious, fast.

An agent that can call APIs, read databases, and execute code is a powerful asset. It is also a powerful attack surface. The defensive posture needs to be specific, not hand-wavy.

Tool permissions and identity. Every agent needs a scoped identity with least-privilege access. No shared service accounts. No persistent admin tokens. Just-in-time access grants that expire after the task completes. If an agent needs to create a Jira ticket, it gets Jira-ticket-creation permissions, not project-admin rights.

Secrets handling. Agents must never see raw secrets in prompts or logs. Vault-based injection at runtime only. Rotate aggressively.

Data exfiltration and logging. Every tool call, every data access, every output must be logged immutably. If an agent summarises a customer database, you need to know exactly which records it touched and what it sent where.

Prompt injection. Indirect prompt injection, where malicious instructions are embedded in data the agent retrieves, is the most underappreciated risk in agentic systems. If your agent reads emails and one of those emails contains a crafted instruction, you have a problem. Input sanitisation, output validation, and strict separation between instructions and data are non-negotiable.

Supply chain risk. Every plugin, connector, and tool an agent can call is a dependency. Vet them. Pin versions. Monitor for changes. This is software supply chain security applied to a new surface.

Agent drift. An agent optimising for a poorly specified goal can take actions that are technically correct and practically disastrous. Bounded action spaces, spending limits, and automatic circuit-breakers are essential.

Auditability and non-repudiation. If an agent takes an action with real-world consequences, you must be able to prove what it did, why, and under whose authority. Signed execution logs. Immutable audit trails. No exceptions.

The bot sprawl problem

Every week brings a new branded crawler or bot: MoltBot, ClaudeBot, GPTBot, whatever it calls itself this week. The naming churn is funny. The underlying issue is not. It signals an ecosystem that has not yet settled on standards for identity, behaviour, rate-limiting, or consent. Until the agentic ecosystem matures enough for common protocols and governance frameworks, expect friction, duplication, and a healthy dose of "who authorised that?"

Where this lands

Agents are real. They are useful. In narrow, well-scoped domains with clear decision gates and robust logging, they are already saving serious time and reducing errors. But they are not magic, and they are not ready to run unsupervised in high-stakes environments.

The organisations that get this right will treat agents the way good militaries treat autonomous systems: useful, powerful, and never trusted without oversight, accountability, and a very clear kill switch.