Last winter one of our weekend students, a junior accountant at a small firm in Blue Area, asked the AI assistant on her laptop to "reconcile these invoices against the bank export." A year earlier the same request would have got her a polite paragraph about how reconciliation works. This time the tool opened both files, matched the rows, listed the gaps and drafted three reminder emails, then stopped and asked whether it should send them. She hadn't written a line of code. She had, without quite noticing, started working with an agent.

We've taught agents to a few batches at CSA now, and we have opinions. Some of the hype is deserved. A lot of it isn't. This post is our attempt to draw that line honestly, from a classroom in Islamabad rather than a conference stage.

A chatbot answers. An agent acts.

People use the word "agent" for anything with a chat box, so let's be strict. A chatbot takes a message and returns a message. An agent takes a goal, plus access to tools and data, and returns a result after doing a series of things. Same model family underneath. The difference is the loop it runs in and the permissions you've handed it.

The bit that matters most in the story above is "then stopped." A good agent isn't fully independent. It works within limits and hands control back at the moments that count, which for our accountant meant before an email went out with the firm's name on it. When students first try agents they tend to either trust them completely or not at all. Neither is right. Think of a very quick new hire who needs clear boundaries and you're close.

What's actually happening in the loop

Strip away the branding and every agent is three steps on repeat.

Plan. Read the goal and everything learned so far, split the work into steps, pick the next tool.
Act. Call the tool. Read a file, run a query, search the web, execute a script, draft a message. Tools are just functions that the software around the model lets it use.
Observe. Look at what came back (data, an error, a screenshot), adjust the plan, go round again.

It stops when the model decides the goal is met, hits a limit the developer set, or needs a decision only a person can make. What made this reliable over the past two years is that models got much better at three specific things: staying on a long list of instructions without drifting, noticing when a tool result contradicts what they assumed, and asking rather than guessing. We show students an older model and a current one attempting the same ten-step task, and the difference is not subtle.

Two supporting pieces matter almost as much as the model. Memory, so the agent keeps notes and remembers what it tried last run. And standard tool descriptions. The Model Context Protocol (MCP) lets any agent talk to any data source that publishes a standard list of its tools, which is why the number of things an agent can plug into has grown so fast.

Where they earn their keep today

Software development is the clearest case, and honestly it's why we added a vibe-coding course this year. A coding agent can take a ticket, poke around a code base, write the change, run the tests, fix what broke and open a pull request. Two-person startups use them. So do large banks.

Outside coding, a few patterns keep showing up in the companies our graduates join.

Research and reporting. Pull from several systems, draft a report with sources, hand it to a person to edit.
Back-office operations. Reconciliations, copying data between systems, invoice matching, ticket triage. Repetitive, rule-based, checkable.
Customer support. Look up an order, issue a refund under a limit, escalate anything odd.
Analytics. Write SQL against a governed data model, produce a chart, explain what moved, with an analyst checking the logic.
Computer use. Drive a browser or desktop app the way a person would, for the many systems in Pakistan that have no API at all.

Notice what these share. The work is valuable, repetitive and verifiable. Where a result can be checked, agents do well. Where it can't, organisations are moving slowly, and we think that caution is exactly right.

Autonomy is a ladder, not a switch

Bottom rung, the AI answers and you do everything else. Next, it proposes actions and you approve each one. Then it runs multi-step tasks and checks in at milestones. At the top it works unattended inside a defined boundary, something like "process refunds under PKR 5,000 for verified orders," with the logs reviewed afterwards.

Almost every real deployment we've seen sits on the middle two rungs. Fully unattended agents get narrow, low-risk work. The sensible move is to climb one rung at a time as trust builds. A distributor we worked with wanted to go straight to the top rung for stock reordering. We talked them into approval-per-order for a month first, and the first week's logs showed why.

The risks, and why they don't scare us

Three things deserve real attention. An agent can take a wrong action, not just give a wrong answer, and a deleted file or a sent email can't be recalled. Agents read a lot of content, and some of it may contain text written to trick the model into doing something harmful (prompt injection). And it's very easy to over-trust something that looks confident and busy.

The fixes are the controls a good manager would put around a new employee. Minimum permissions. Approval for anything irreversible. A log of every tool call so the work can be audited. Treat whatever the agent reads as data, not instructions. Keep a named human responsible for the outcome. None of this is exotic, and we make students set it up in week six of the vibe-coding course before they're allowed to automate anything that sends a message.

What it means if you're a student here

Good news first. The cost of producing work has collapsed. A student in Rawalpindi with a laptop and an agent can build a working web app, analyse a real data set or draft a professional report over a weekend. Tuition centres, Daraz sellers and textile exporters need exactly this help and can't pay for a team. Freelance platforms already list work for people who can direct agents well, and some of it pays in dollars.

Now the condition. The value has moved from producing the work to specifying it, checking it and being responsible for it. An agent can write SQL, but it can't know that your company counts a refund differently from a return. It can draft a report, but it can't tell whether the numbers are plausible for a Faisalabad mill in cotton season. That judgement comes from fundamentals and from the habit of checking. We've watched students who skipped SQL basics produce agent output that looked polished and was wrong in the second column.

So our advice is unglamorous. Learn the fundamentals properly, because they're what let you judge an agent's output. Start using agents early, because the tools reward practice. Learn to write clearly, because the prompt is now the most important document in the project. Every course on our courses page has been reworked around that combination, and we think it's the most employable skill set a young person in Pakistan can build right now.

If you remember one thing

Agents are a loop with tools, not magic. They shine on valuable, repetitive, verifiable work, and they need the same guardrails you'd give a fast new hire. Your job is shifting from doing the work to specifying and checking it. Fundamentals plus agent skills plus clear writing is the combination we'd bet on.

The Rise of Agentic AI: From Chatbots to Autonomous Co-workers