Agentic AI, honestly: what actually works in 2026

The shift nobody explains properly

I remember the exact moment the ground moved under me. I had asked a model to rename a variable across a project. Instead of printing steps for me to follow, it opened the files, made the edits, ran the tests, noticed one test failed because of a string it had missed, fixed that too, and told me it was done. Nothing in the screen had changed. But my job had.

That is the whole difference between a chatbot and an agent, and it is smaller than the hype suggests. An agent is a model given three things: tools it can call, a loop it can keep running in, and permission to decide when to stop. Take away any one of those and you are back to autocomplete with good manners.

This matters because it tells you where the risk sits. A chatbot can only waste your time. An agent can delete a folder, send an email, spend money on an API, or cheerfully commit a change nobody reviewed. The thing that separates people getting real value from people posting screenshots is not prompt cleverness. It is designing the fence the agent works inside.

Inside the agent loop

Strip away the frameworks and every agent runs the same four beats. It looks at the current state, picks one action, performs it with a tool, then reads the result and starts again. That is all. Every bit of sophistication in this industry sits in how each beat is kept in check.

Where loops break in real life

The problem is almost never that the model is stupid. It is that the result of step two never reached step three in a usable shape. Real examples from my own week:

• A tool returned four thousand lines of log output, which pushed the original instruction out of the useful part of the context. The agent forgot the goal and started debugging the log format instead.
• A search tool returned an empty list. Nothing said no results in plain words, so the model invented believable results rather than admitting failure.
• Two tools could both technically handle a step, with overlapping descriptions. The agent flip-flopped between them for six turns, which is an expensive way to do nothing.

The fixes are boring and they work. Cut tool output down and summarise it before it goes back into the loop. Make failure loud and readable, something like zero results found, try a broader query. Give every tool one obvious job and a description that also says when not to use it. Cap the number of turns, and make the agent say what it plans to do next before it does it.

One agent or a whole crew

Multi-agent diagrams look great in slide decks. In day-to-day work, one solid agent with excellent tools beats five agents passing half-understood notes to each other almost every time. Handoffs lose context, and lost context is where made-up answers grow. Split the work only when the pieces genuinely do not need to know about each other, like a research pass feeding a writing pass, where the note in between is short enough for you to read yourself.

A quick test before adding another agent: could I explain the handoff in one sentence to a new colleague? If not, the second agent is decoration.

Give the loop a memory it can trust

Long tasks need a small written record, not a longer chat. The setups that hold up best keep a short running file of decisions taken and things ruled out, and feed that file back in each turn instead of the whole history. It is the same reason a builder keeps a job sheet rather than trying to remember six weeks of conversation.

Context work beat prompt tricks

The most useful shift of the last two years got the least attention. In 2023 the question was what should I type. In 2026 the question is what should the model be able to see, and in what order. Prompt writing became a small part of a bigger craft: putting together the right context for a task.

In practice that means paying attention to four things.

Position, not just presence

Long-context models can technically hold a small library. That does not mean they read all of it evenly. Whatever sits at the very start and the very end gets treated as more important than the middle. So put the instruction and the pass or fail rules at the end, right before you ask for output, not buried above ten thousand tokens of reference material.

Fewer files, better chosen

Pasting a whole codebase or a ninety page PDF feels thorough and usually makes the answer worse. Every extra paragraph is another chance for the model to grab the wrong thread. Three well chosen files beat thirty. If you cannot say why a document is in there, take it out.

Show the shape of the answer

One example of the output you want is worth several paragraphs describing it. If you need a table with four columns and no commentary, paste a two row version of that table. Models copy structure far more reliably than they follow words like concise or professional.

Give it somewhere to think

Reasoning models do better when they are allowed to work before answering, and worse when you demand a one line verdict straight away. On the other hand, do not pay for deep thinking on a task like reformatting a list. Matching effort to difficulty is where most of the real savings hide.

The habit that changed my results most

I keep a plain text file for each task I do again and again: the goal, the limits, two examples, and a list of mistakes made before. It is dull. It also beat every clever prompt template I ever tried, because it builds up over time. Prompts are throwaway. Briefs compound.

The tools, at a deeper level

You already know these names. What follows is not a feature list. It is where each one earns its place in a working setup, and where it does not.

ChatGPT, the generalist that remembers you

Its real edge is not raw reasoning, it is continuity: memory that sticks, saved instructions, and the ability to move between browsing, running code and reading files in one thread. Deeper use looks like keeping separate projects or instructions per line of work, so your writing voice does not leak into your data analysis. Its weakness is eagerness. It will agree with a shaky plan if you present it with confidence, so ask it to argue against your approach before you commit.

Claude, the one I trust with long documents and real code

Claude tends to stay close to a long source without smoothing over details, which makes it my default for contracts, research and any job where inventing a fact is unacceptable. It is also unusually willing to say this is not in the document. Deeper use: ask it to plan first and act second, and let it write the small change rather than the whole file. Where it struggles is short casual work, where the careful thinking just feels slow.

Gemini, the one that sees and the one that scales

Its edge is genuinely mixed input at large size: a screen recording, a stack of screenshots, an hour of audio, a sheet too big to paste. When the job is look at this and tell me what happened, it is often the quickest route to an answer. The catch is that a huge window invites lazy questions. Ask about specific pages or timestamps instead of asking it to summarise everything.

Cursor, for people who read the code they ship

Cursor is not really about autocomplete. Its value is that the model shares your project mental model. The people who get the most from it treat it as a very fast pair, not a replacement: small scoped requests, a rules file describing house style, and every change read before it lands. Used carelessly it leaves you with a codebase nobody understands, which is the most expensive kind of speed.

Lovable, for turning an idea into a working link

This one sits in a different category. Instead of helping you write software, it builds and hosts the whole thing, interface, database, logins and deployment, out of a conversation. The real trick is scope discipline. Describe one screen and one flow at a time, check it works, then move on. People who dictate a whole product in one paragraph get something impressive looking and hard to steer. People who go in small steps end up with something they can actually launch.

How to choose without agonising

• Long document, high accuracy, no room for invention, go with Claude.
• Images, video, audio or a big mixed pile of input, go with Gemini.
• Ongoing general work where memory of your context helps, go with ChatGPT.
• Editing a real codebase you maintain, go with Cursor.
• Shipping a working app or prototype end to end, go with Lovable.

Two subscriptions used deeply will always beat six used shallowly. The switching cost is not the money, it is the context you rebuild every time you move house.

Where agents actually pay off at work

Strip out the demos and a clear pattern shows up. Agents earn their keep on work that is repetitive, well defined, and easy to check. They lose money on work that is rare, fuzzy, or only verifiable weeks later.

Jobs that go well

• Turning messy input into a fixed format: invoices into rows, emails into a tracker, notes into a task list.
• First drafts with a strong template, where your edit pass is faster than starting cold.
• Reading something long and pointing at the three parts that need a human, rather than deciding anything itself.
• Small code chores with tests around them, like renames, migrations and version bumps.

Jobs that go badly

• Anything sent to a customer without a person reading it first.
• Judgement calls that depend on office context the model cannot see.
• Work where being slightly wrong is invisible, like tweaking numbers in a report nobody reconciles.
• One off tasks, where writing the setup costs more than just doing the job.

A simple rule I use before handing anything over: if I would not let a smart new intern do it unsupervised on day three, an agent should not do it unsupervised either.

How to read AI news without being fooled

The AI news cycle is built for reaction, not accuracy. A benchmark number travels across timelines in an afternoon, while the footnote saying it used a different test never travels at all. Four filters I run before believing anything:

1. Find the primary source. A company post, a model card, a paper, a filing. If the only source is a screenshot of a screenshot, wait.
2. Ask what was measured. Best in class on a test that looks like its own training data is not the same as being better at your work.
3. Separate a demo from availability. A staged video is a promise. Check whether the thing is in general release, in a limited preview, or on a waitlist that never opens.
4. Wait a week on anything alarming. The scariest AI stories of the last two years were mostly rounded corners, missing context or misread charts. A week costs you nothing and saves you being wrong loudly.

One more habit that has served me well: keep a note of the predictions you read, with dates. Reading it back after six months is the fastest way to learn whose analysis to trust.

Five ways things go wrong

Confident wrongness that looks correct

The dangerous errors are not obvious nonsense. They are a believable library that does not exist, a citation with a real author and a fake title, a number that is off by a factor of ten. Check anything with a specific value: names, versions, prices, dates, statistics.

Quiet scope creep

Ask an agent to fix one function and it may also reformat a file, rename something, and improve logic you never mentioned. Say it plainly: touch only these files, leave everything else alone.

Context rot in long sessions

After a couple of hours, quality slides. Earlier corrections get forgotten and contradictions pile up. Start a fresh session with a short summary of what has been decided. It is faster than fighting a tired context.

Agreeing with you

Models are trained to be helpful, which makes them poor critics of your own idea by default. Ask for the strongest objection, or ask the same question in a second session without hinting at the answer you want.

Automating a process you never understood

The worst outcome is not a bad answer, it is a workflow that runs unwatched and produces slightly wrong results for weeks. Automate only what you could still do by hand, and keep a human checkpoint wherever an action cannot be undone.

Keeping your data out of trouble

This part gets skipped in most guides, and it is the one that can actually cost you a job. Anything you paste into a tool leaves your machine. That is fine for a blog draft and not fine for a client contract, a customer list or a colleague medical detail.

A short checklist that saves arguments later

• Strip names, phone numbers and account numbers before pasting. A find and replace takes ten seconds.
• Check the settings for training on your data, once per tool, and write down what you chose.
• Keep work and personal accounts apart, so memory features do not mix the two contexts.
• Never give an agent standing access to a mailbox or a payment method without a spend limit and a log you read.
• Assume anything in a shared chat link is public. If it would embarrass you in a group chat, do not paste it.

The cost model people get wrong

Everyone measures the subscription. Almost nobody measures checking. If a model drafts something in thirty seconds and you spend twenty minutes working out whether it invented anything, that task did not get cheaper. It got faster and riskier.

The jobs with genuinely good economics share one trait: checking is cheap. Code with tests around it. A translation you can read. A summary sitting next to its source. A draft you were going to rewrite anyway. The bad ones are where a mistake stays invisible until much later, like legal wording, medical detail, money figures, or anything sent to a customer unread.

Before you automate anything, ask how you would notice it had gone wrong. If you have no answer, that is the thing to fix first.

Skills worth building now

People keep asking what to learn so this does not pass them by. My honest answer is that none of it is about the tools.

• Writing a clear brief. If you can describe a job so a stranger could do it, you can get a model to do it. Most bad output is a bad brief in disguise.
• Judging work quickly. The scarce skill is not producing a draft, it is telling in two minutes whether a draft is worth keeping.
• Knowing your own domain deeply. Models are strongest where you can spot their mistakes, and most dangerous where you cannot.
• Breaking work into steps. Nearly every agent failure I have seen was a task that should have been three smaller tasks.
• Being comfortable saying no. Half of good AI use is deciding a job does not suit a machine and just doing it yourself.

A realistic first month

If this all feels like a lot, here is the order I would give a friend. It leaves you with a working setup instead of a folder of half finished experiments.

1. Week one. Pick one task you already do well and often. Write a brief for it: goal, limits, two examples of good output. Run it by hand with one model for five days.
2. Week two. Note every correction you make. Fold those corrections into the brief. This one habit explains most of the improvement people credit to better models.
3. Week three. Add one tool, maybe search, a file, or your codebase, and see whether quality actually improves. Take it away again if it does not.
4. Week four. Only now let it run steps on its own, with a hard cap on turns and a checkpoint before anything you cannot undo.

None of that is exciting. But four weeks of it beats a year of chasing releases, and it leaves you with something rarer than a clever prompt: a clear sense of what these systems are good for, and where you should still do the thinking yourself.

What I would tell my past self

Two years in, the mistakes I made were not technical. They were about attention. I chased every launch, kept twelve tabs of tools open, and mistook that busyness for progress. The work only improved when I got dull about it.

Pick one job and finish it properly

One task, done well with a written brief, taught me more than fifty experiments started and abandoned. Depth shows you the failure modes. Breadth only shows you the demo.

Keep your own writing muscle warm

If a model drafts everything, your sense of what good looks like slowly fades, and then you cannot judge the drafts any more. I still write first paragraphs by hand for anything that matters, and let the tools help with the middle.

Trust the boring measure

Not tokens, not model names, not benchmark charts. Just this: did the work get better, and did the day get lighter? If neither is true after a month of using something, drop it without guilt. There will be another tool next week, and most of them will not matter.

Questions people keep asking

Do I need to learn coding to use agents well

No, but you do need to be comfortable reading structured things, whether that is a spreadsheet, a checklist or a config file. The people who struggle are usually the ones who never look at what the agent actually did.

Is the most expensive model always the right one

No. On a task where the answer is short and the rules are clear, a cheaper model with a good brief often wins, because you can run it three times and compare. Save the heavy models for reasoning you cannot shortcut.

How many tools should one agent have

Fewer than you think. Five clear tools beat fifteen fuzzy ones. If two tools could handle the same step, merge them or delete one.

Will this replace my job

It will replace parts of most jobs, and the parts it takes first are the ones that were already written down as a procedure. The safest place to stand is where judgement, context and responsibility meet, because someone still has to sign off.

Can I trust an agent with my company data

Only with the slice it needs for the task. Give it read access first, keep write access behind your own approval, and never paste keys or customer records into a chat window when a scoped tool call can do the same job.

Why does the same prompt work one day and fail the next

Usually the session, not the prompt. A long thread carries old decisions the model keeps honouring. Start fresh, paste a short summary of where you are, and the odd behaviour often disappears.

How do I know when to stop an agent mid task

When it repeats a step it already tried. One retry is normal, two is a loop, and a loop burns money without getting closer. Stop it, read the last few steps, and fix the brief instead of the model.

That is the honest summary. Agentic AI is real, useful, and much less magical than the timeline suggests. Treat it like a fast, tireless, slightly overconfident colleague. Give it clear briefs, check its work, and never let it push to production alone.

Found a mistake, or disagree with something here? I would genuinely like to know. The contact page reaches me directly, and corrections get published with a date. You can also read more about who writes this and how.