For the last couple of years, most AI tools have worked like a very smart colleague who only gives advice. You ask, it answers, and then you go and do the thing.

July made it clear that this is changing. Within a few days of each other, two launches pointed in the same direction: AI that doesn't just tell you how to do a task, but goes and does it.

What happened

On 17 July, OpenAI launched ChatGPT agent. It combines two things OpenAI had already shipped separately: Operator-style browsing, where the AI clicks through websites on your behalf, and deep research, where it gathers and synthesises information from many sources. The agent works on its own virtual computer, so it can move between browsing, research and other steps within one task.

A few days earlier, on 14 July, AWS previewed Kiro, an AI IDE built around spec-driven development. Instead of starting with "write me this feature", the idea is to start with a specification of what should be built, and let the AI work from that.

Different products, different audiences. Same message: the industry is betting on agents.

What "agentic" actually means

The word is everywhere right now, so it's worth pinning down. A chat assistant takes one input and gives one output. An agent runs a loop:

1. Look at the goal and decide on the next step.
2. Use a tool: open a page, run a command, read a file, call an API.
3. Look at the result.
4. Decide what to do next, and repeat until done (or stuck).

That's it. The intelligence is the same kind of model you already chat with. What's new is that it's connected to tools and allowed to take many steps without asking you after each one.

Developers have been living with this for a while already. Claude Code, OpenAI's Codex, GitHub Copilot's coding agent, Google's Jules and Gemini CLI all work this way in a codebase: read files, make changes, run tests, try again. ChatGPT agent brings the same loop to everyday tasks on the web, for a much wider audience.

Why spec-driven matters

Kiro's angle is the more interesting one for developers, I think. Anyone who has used a coding agent knows the failure mode: you give a vague instruction, the agent confidently builds something, and it's a reasonable solution to a slightly different problem.

Writing the spec first is an old idea, and it fits agents unusually well. A clear statement of requirements and design gives the agent something to work from and gives you something to check the result against. It's the same reason a CLAUDE.md file with project rules, or a well-written ticket, makes any coding agent noticeably better. The more an agent does on its own, the more the quality of the instructions decides the quality of the outcome.

The risks, before the excitement

An AI that can act is more useful and more dangerous than one that can only talk. A few things worth thinking about before handing over real tasks:

• Prompt injection gets real teeth. An agent browsing the web reads content written by strangers. A malicious page can contain instructions aimed at the agent. When the agent can click "buy" or "send", that's no longer a curiosity.
• Mistakes happen at machine speed. A wrong assumption in step two can carry through twenty more steps before anyone looks.
• Credentials and access. Whatever the agent can log into, it can act on. Give it the least access that does the job, and be wary of handing it accounts with payment details or admin rights.
• "Done" isn't "right". Agents report success confidently. Check the actual result: the booking, the form, the diff, the test output.
• Accountability stays with you. If the agent sends the wrong email from your account, it's still your email.

The sensible pattern, in any agent product, is the same one I'd use when building agent features: let the agent research and prepare freely, and require a human confirmation for anything with consequences, like payments, messages, deletions or purchases.

What this means if you build web apps

Here's the angle I don't see discussed enough. If agents start using websites on people's behalf, some of your users' sessions won't be people. That has practical effects:

• Clear, well-labelled forms and predictable flows help agents and humans alike. Good accessibility practice already points the same way.
• Important actions should have explicit confirmation steps that a human can review.
• Endpoints that create things should be safe to retry, because agents retry too. Idempotency stops a confused agent from ordering something twice.
• Rate limits and abuse detection need to distinguish "an agent acting for a real user" from "a scraper", which is not a solved problem.

The short version

ChatGPT agent and Kiro are two sides of the same shift: AI moving from answering to acting, for everyday users and for developers. The useful skills for this era are very human ones: writing clear specs, setting sensible permissions, and checking the work.

Would you let an agent complete a real task for you today, like booking something or submitting a form with your account? Where do you draw the line?