Agentic AI in the Workplace

How these tools work, and where they differ from a chat window

The change is not that the model got better at answering questions. It is that these tools open the real files. An agent works inside your codebase or your document store, takes several steps in a row, runs what it writes, checks its own output, and hands back something a person can inspect: a diff, a draft, a set of edited files. In a chat window you describe the work in words and paste the answer back yourself; here the work is done where the work lives.

Context is what actually changes the quality of the result. The agent sees the real thing your team works on, not only the description you managed to type out.

• Claude Code: an agent that works on the real codebase from the terminal, reading, editing, running tests and explaining what it just did
• Claude Cowork: an agent that takes document work and everyday tasks as a continuous sequence of steps, rather than one instruction at a time
• OpenAI Codex: another coding agent in wide use, chosen to suit what your organisation already runs and what your data rules allow
• The tooling around them: connecting agents to code repositories, ticket systems and internal document stores so they work on real material

Not just for the engineering team

The names sound technical, and the first people to pick these tools up usually are the engineers. But what agents are good at is bounded work with a result you can check, and that exists in almost every function. In practice the teams that get value fastest are not the ones with the strongest coding skills; they are the ones who can describe their own work as a clear sequence of steps.

• Engineering: bugs with a defined scope, writing tests, and reading through old code nobody on the team knows any more
• Data analysis: scripts to pull and clean data, and the same summary tables that have to go out every month
• Operations: reformatting files, checking data for completeness, and moving records between systems
• Documentation: bringing manuals in line with a system that has just changed, and drafting new material from what already exists
• Support: summarising open cases, and drafting replies from the internal knowledge base for a person to check before they go out

Running the rollout so it does not stall after the pilot

Pilots rarely stall because the tool disappointed anyone. They stall because the class ends and nobody owns what comes next, there is no real work waiting, and the person who has just worked out a way of using it well has nowhere to put that.

So the work starts on your own briefs from day one. The one-day course we have already run, Claude Cowork & Agentic Workflow for Real Business Projects, uses the organisation's own project briefs as the exercises for the whole day, so people leave with work that can carry on rather than a worked example. What follows the course is planned in the same spirit: named owners and scheduled review points, instead of leaving it to one person's enthusiasm.

• Start with the one-day course, using your own business briefs as the exercises
• Pick a few starting tasks that repeat and are easy to check, rather than opening everything at once
• Name an owner in each team; do not leave it as volunteer work
• Keep one shared place for prompts, patterns and examples that worked, so the next people do not start from nothing
• Schedule a review once it has been in real use: keep what worked, drop what did not
• Grow the next group out of the people already using it, not out of a slide deck

Guardrails, and the limits worth being honest about

An agent that can edit real files needs a written boundary: what it may touch and what it may not. Everything it produces goes past a person before it is merged or sent out. And which classes of data may leave the organisation (customer records, personal data, contracts) is settled in advance rather than case by case.

Being straight about it: these tools are good at bounded work with a checkable result. They are not good at decisions that belong to the organisation, and there always has to be someone at the end who can tell whether the output is right or wrong. If nobody on the team can check a piece of work, that is not the piece of work to hand over first.

• Set out which repositories, directories and systems an agent may reach
• Everything goes through human review before it is merged or sent out
• Separate the data tiers, and agree in advance how confidential and personal data is handled, in line with PDPA
• Keep a record of who asked for what, and what the agent changed
• Always start with work whose result can be checked; if it cannot be checked, it is not ready to hand over