An AI agent's first feature should be a boundary

The most interesting question about an AI assistant is not always which model it uses.

Sometimes it is a much less glamorous question: what is this assistant not allowed to do?

My work on an operations platform has made that question more concrete. There is a substantial difference between asking an assistant to research a public topic and allowing it to change infrastructure, send a message, or make a commitment on someone's behalf.

Those are different products, even if they happen to share the same chat interface.

I think the first useful feature is a boundary: a clear description of the job, the available information, the permitted actions, and the conditions for stopping.

Start with one job, not an open-ended role

"Be my assistant" leaves too much unstated.

Compare that with a hypothetical task: compare three public tools against a supplied set of requirements, return the sources and trade-offs, and stop after producing a recommendation. Do not create accounts, contact vendors, or purchase anything.

The second request has an output someone can evaluate. It also exposes the decisions that remain with the person.

That is a useful starting point for a pilot. It makes it easier to learn whether the assistance is valuable before connecting more data or granting more authority.

The goal is not to keep the assistant permanently limited. It is to make each expansion of responsibility an explicit decision.

Access and authority are separate questions

There are at least three decisions to make:

• What information can the assistant read?
• Which tools can it call?
• Which effects can it cause?

They should not be bundled together merely because a connector supports all three.

Reading a calendar is not the same as creating an invitation. Drafting a message is not the same as sending it. Inspecting a deployment is not the same as changing it.

There is a similar distinction between a role description and an enforced boundary. Calling one profile a researcher and another an operator does not create isolation if they share the same credentials, storage, and execution privileges.

Instructions matter, but they are not a substitute for tool restrictions, scoped credentials, network controls, and authorization checks outside the model.

The implementation must match the promise made in the interface.

Unavailable is not the same as empty

An assistant that cannot access a source should say so.

It should not turn "I cannot read your calendar" into "you have no meetings." It should not turn a failed search into a confident statement that nothing exists.

This distinction sounds small until a person starts relying on the answer.

A useful response separates observed facts, supplied information, assumptions, and missing evidence. Public web content also needs to remain source material, not become an instruction that silently changes the assistant's job or permissions.

I would rather see a precise limitation than a complete-looking answer assembled from guesses.

A conversational promise is not a task record

"I'll take care of it" is not an operational state.

For work that continues beyond a single response, I want an identifiable task with a scope, an owner, a status, and a completion condition. The result should distinguish completed work from a failed attempt, a blocked dependency, or a recommendation awaiting a decision.

Retries need similar discipline. If a request times out after creating something, repeating it may produce a duplicate rather than a recovery.

Where a system supports idempotent operations, use that mechanism. Otherwise, make the uncertainty visible and check the recorded state before trying again.

This is not a problem unique to AI. AI simply makes it easier to hide the ambiguity behind fluent language.

Bound the cost of being wrong

A task needs more than a desired answer.

It also needs limits: time, spending, retries, tool calls, and the ability to create follow-up work. Which limits matter depends on the system, but the absence of limits should be an intentional choice, not a default discovered through a bill or a runaway queue.

The enforcement needs to sit in the execution path. A sentence asking a model to stay under a budget is not the same as a service refusing a request that would exceed it.

Stopping is a valid outcome. A bounded task that reports why it could not finish is more trustworthy than one that keeps expanding its scope until it can produce a success-shaped response.

Approval should be specific

Adding a human approval button does not, on its own, make an action well controlled.

What exactly is being approved? Which destination, content, resource, cost, and scope does the approval cover? Can any of those change between the preview and execution?

For consequential actions, authorization should apply to the specific proposed action and be checked again when it is executed. A general instruction to "help with operations" should not silently become permission to make every future change.

The person also needs a useful description of the consequences. Approval without that context is just another click.

Useful autonomy is earned through evidence

The purpose of these boundaries is not to make the assistant less useful.

It is to make its usefulness understandable.

Can it complete the bounded job? Does it preserve the distinction between evidence and inference? Does it stop when information or authority is missing? Can someone inspect what actually happened?

Those are better reasons to expand a pilot than the fact that a larger model or another connector became available.

My interest is in assistance that removes friction without making responsibility harder to locate. A boundary is not the opposite of that ambition. It is part of the design.