A project contributor thanked me for reporting a bug. There was only one problem: I hadn't reported it. At least, not knowingly.

I had been investigating the bug with help from AI coding agents. I had given the agent involved access to my cloud account and GitHub. Somewhere along the way, it went from helping me investigate to filing a bug report in the repository under my account.

That reply was the first I knew of it. An unusually efficient way for GitHub to introduce me to a conversation I had apparently started.

The bug itself isn't important here. What matters is the route from investigation to publication. The agent hadn't broken into anything; I had given it access. That explains how the report could be filed, but not whether I had knowingly authorised that particular action. My request may have been ambiguous, or a confirmation may have been unclear. Whatever the immediate cause, my expectation and the system's behaviour did not match.

That small incident changed how I think about AI agents and agentic AI. I became less interested in which label sounded more autonomous, and more interested in what I had actually handed over: freedom to investigate, permission to act, or both?

How I Make Sense of the Terms

This is the working definition I find most useful:

An AI agent is a system that observes information and takes actions towards a goal. Agentic describes the discretion a system exercises in pursuing that goal.

Agentic AI is the broader term for systems or approaches that show this behaviour. It might involve one agent or several; a single agent can also be the entire system.

These aren't settled definitions. Some people use "agent" for almost any tool-using AI application; others reserve it for systems where the model chooses each next action. For me, the useful distinction is between what has been built and how independently it operates.

Planning, changing approach and deciding when to ask for help can all show agentic behaviour. But counting agents doesn't tell me much. One might plan an investigation as it goes; several might follow a rigid script. More agents, in that case, but not more discretion.

Why I'd Start Small

For a simple application built around a large language model (LLM), I'd start with:

LLM + instructions or prompts + tools.

This is a useful shorthand, not a universal definition: agents predate LLMs. Here, the model interprets the request, instructions describe the task and expected behaviour, and tools provide operations such as searching documents or creating a GitHub issue.

That can be enough. The model picks a search query, calls an approved search tool once and uses the results to answer. Then the application ends the task. No long-running planner, no team of agents. Just a small, useful piece of software.

Adding a Loop

The next step might be to give the tool result back to the model and let it decide whether another action would help:

Choose an action, observe the result, decide what comes next, repeat or stop.

The loop itself may take very little code. Making it dependable is another matter. How many steps are allowed? How much time and money can it use? What happens when a tool fails, or the agent keeps searching without getting anywhere? Those limits need to be part of the application.

I also wouldn't call every loop more agentic. Running a developer-defined search three times is still a fixed procedure. Letting the model weigh the evidence, revise its search and choose when to stop gives it more discretion. That's the difference that matters here.

Memory, planning and delegation can come later if the task needs them. They're optional; there's no reason to add the whole lot at once.

Small Doesn't Automatically Mean Safe

Take an assistant that searches a local collection of public documentation and drafts an answer for someone to review. The model runs locally. Its only tool reads that collection, and the application enforces a small request budget. There is no access to private files, messaging, write operations or a general-purpose terminal.

For an ordinary reference task, I'd consider that a useful, low-risk starting point. It cannot create a GitHub issue because it has no operation that can create one. That is a much firmer restriction than asking it, in a prompt, not to post anything.

It can still give a misleading answer, so I wouldn't take this as an endorsement for high-stakes advice. But many consequential actions are unavailable by design, and the user's request authorises only the bounded search and draft.

Now let it refine its search up to three times. It has gained a loop and a little flexibility. It still cannot publish, spend money or change records. More iterations do not have to mean more permissions.

Simplicity makes a system easier to inspect and test, but it isn't the protection on its own. The protection comes from narrow capabilities and enforced limits. A tiny agent with an unrestricted execution tool would be a very different proposition.

The Difference I Had Overlooked

I find the distinction easier to see through three ways of configuring a GitHub assistant. These are examples, not a reconstruction of what happened to me.

A Fixed Workflow

The application takes a supplied bug description, asks an LLM to turn it into an issue draft and shows the result. The developer has already set the sequence. AI is doing part of the work, but it has little say over what happens next.

Adaptive Investigation

The agent searches existing issues, checks the relevant documentation and decides whether to keep investigating or ask for missing information. An unhelpful search can lead it to try a different approach. That's agentic behaviour, even if all it can do is read authorised material and prepare a local draft.

External Action

Now give the same agent permission to create issues. It can change something outside the conversation. Its reasoning hasn't necessarily become any more sophisticated; it simply has more authority.

This is the distinction I keep coming back to: autonomy over the process and permission to affect the world are separate dimensions. An agent can investigate independently and still have to ask before it posts anything.

I'd choose more discretion when the next step depends on what the system discovers, and a fixed workflow when I already know the sequence. Neither is automatically safer. A read-only research agent may have less scope to cause harm than a simple automation that can email thousands of customers. Read-only access still needs care with confidentiality and inaccurate answers.

Three Boundaries I Want to Make Explicit

Investigating a bug, preparing a report and submitting it are different commitments to me. I want those transitions to be visible before anything gets posted. These three boundaries help me describe what I mean; they're practical design questions, not formal industry standards.

1. Decision Boundary: What May It Choose Independently?

The decision boundary covers choices delegated to the system within a stated goal. What may it investigate? Which alternatives may it choose? When must it stop or ask for clarification?

I might let a GitHub assistant choose search terms, inspect related issues and recommend whether a new issue is warranted. I wouldn't take that to include changing code or contacting maintainers. Those are different tasks.

Example rule: Investigate the reported problem in the named repository, make up to five searches and prepare a recommendation. Ask if the repository is unclear or the task requires a different goal.

Five searches isn't a magic number. The limit is a design choice; the point is to have a stopping condition we can observe and test. "Use your judgement" doesn't give us that on its own.

2. Action Boundary: What May It Read or Change?

The action boundary covers the operations and resources available to the system: what it can read, modify, publish, execute or spend. Tool names alone aren't enough; limits should also cover targets, volume and duration.

"Has GitHub access" tells me too little. Reading an issue, creating one, merging code and changing repository permissions are very different capabilities.

Example rule: Read issues in the selected repository and prepare a draft locally. Permit creation of one approved issue through a controlled tool, but do not permit code changes, deletion or permission changes.

These restrictions need to live in tool permissions and application code, not just in prompts. Otherwise, a broadly privileged terminal or another API may offer a way round them. Blocking one route doesn't help if a second route remains open.

3. Consent Boundary: What Requires Specific Authorisation?

The consent boundary identifies which otherwise permitted actions need informed approval, and exactly what that approval covers. Technical access isn't consent to use it here, now, for this purpose.

For my GitHub testing, I'd want to see the repository, issue title and body before submission. The interface should also make the consequence clear: this creates a record outside the chat, visible to people with repository access, and may trigger notifications.

Example rule: Create only the issue whose content and destination I approved. If either changes, ask again. Silence is not approval, and approval for one issue does not cover later issues or comments.

Under a different policy, an explicit request to create a particular issue might already count as authorisation. For my initial experiments, I'd keep a separate confirmation. A little extra friction feels justified there.

Put the three together and the agent may decide to recommend an issue, have conditional access to create it, and still need my approval for this particular submission. Approval cannot override a prohibition: if an operation is forbidden, confirming it must not make it available.

What I'd Test Before Giving It More Access

I'd start with prepare, preview, approve, execute. Then show what actually happened: the created issue's link, for example. "Done" is a bit thin when the action has changed something outside the conversation.

Before granting wider access, I'd test these cases in a controlled repository:

I'd also keep records of approvals, tool calls and results without retaining sensitive information unnecessarily. There should be a stop control and a recovery process. Closing an unwanted issue might help, but it won't undo a notification or take back information someone has already seen. We shouldn't assume the action is reversible.

Passing these tests would tell me something useful about those specific behaviours. It wouldn't prove the system safe in general. I'd still begin with narrow permissions and expand them only for a concrete reason.

Where I'd Still Want a Person Involved

My preference for explicit approval isn't a universal policy. The right boundary depends on the consequences, applicable law, organisational policy and who is entitled to authorise the action. Anything affecting safety, legal rights, sensitive information or substantial financial commitments needs a more demanding assessment, possibly qualified human review or a decision not to automate it at all.

And a confirmation button, on its own, isn't enough. The person reviewing needs the relevant evidence, time to understand the proposal and a genuine opportunity to say no. The agent must not be able to waive its own approval requirements or give itself more authority.

What I'm Taking Forward

I still want agents that can investigate without asking me about every search. But as I add capabilities, I want to revisit the boundaries too: stopping rules for a new loop, reachable operations for a new tool, and consent before publication.

That leaves me with three questions more useful than the label on the product: what may it decide, what may it affect, and what requires my authorisation?

Next time someone thanks me for a bug report, I'd quite like to know which one they're talking about.