Which AI Agent Settings Should Business Owners Control?

Business owners should control the settings that decide what an AI agent may do, what it may see, who approves its actions and what it may spend. Technical choices, such as how documents are indexed or how failed requests are retried, can be left to a provider as long as they stay inside those limits and any change that touches them is reported. A simple test: if a wrong setting would change who sees your data, what you commit to customers or what you pay, the decision is yours.

Key takeaways

• Decisions about authority (actions, approvals, spending, external promises) and exposure (data scope, channels, retention) belong to the business.
• Decisions about mechanics (indexing, retries, caching, logging format, tool design) can belong to the provider, within limits you set.
• Some choices look technical but change your risk, such as swapping the underlying model or widening what the agent remembers. Treat those as business decisions.
• Write the boundary down, name one accountable owner per setting, and require the provider to report any change that touches your side of the line.
• Review the settings on a schedule, because the agent's access tends to grow quietly.

Why does the line between business and technical settings matter?

Most agent setup documents mix both kinds of setting in one long list. Owners then make one of two mistakes. They try to approve everything, which is slow and puts them in conversations they lack the context for. Or they approve nothing and let the provider decide, which means accountability for customers, employees and regulators sits with a party that cannot carry it.

A provider can build and operate the system. It cannot be answerable to your customer when the agent promises a refund, or to your regulator when personal data reaches the wrong place. That is why the shared responsibility model matters: it says in advance who carries which risk. Frameworks such as the NIST AI Risk Management Framework also treat governance as an organizational function, not only an engineering one.

The practical goal is a short list of settings you own, written in plain language, and a clear permission for the provider to handle everything else without asking you each time.

Which settings belong to the business?

These settings define authority and exposure. Each one answers a question only the company can answer.

• Role and purpose: what the agent is for, and what it is explicitly not for. A support agent that drifts into pricing negotiation has left its role, whatever the model is capable of.
• Approval boundaries: which actions the agent may take alone, which need a named human to approve, and what happens when that person is unavailable. The default for anything irreversible or external should be approval.
• Data scope: which systems and folders the agent may read, which it may write to, and which are off limits. This includes whether personal, financial or contractual data is in scope at all.
• Permissions and identity: the accounts the agent uses, what each account can do, and who can grant more. The principle of least privilege, described in the OWASP authorization guidance, applies to agents as much as to people.
• Channels: where the agent speaks, and to whom. Internal chat is a very different exposure from email to customers.
• Spending limits: the ceiling on usage cost, the alert thresholds and who is notified. A practical setup is covered in AI agent usage limits and budget alerts.
• External commitments: what the agent may say about prices, dates, refunds, legal terms or medical and financial advice.
• Retention and training: how long conversations and memory are kept, and whether any provider may use your data to train models. Get the answer in writing.
• Success and stop conditions: the observable measure that says the agent is doing its job, and the condition under which it is paused.
• Account ownership: who holds the model accounts, keys and workspace, and what you can export if the relationship ends.

None of these require technical knowledge. They require knowing your business, your customers and your obligations.

Which choices can a provider make for you?

These settings change how well the agent works, not what it is allowed to do. A competent provider should make them without a meeting, document them and test the result.

• Retrieval design: how documents are split, indexed and searched so the agent finds the right passage.
• Prompt and context structure: how instructions, memory and retrieved material are arranged for each request.
• Tool design: how each tool is described and what inputs it accepts, so the agent uses it correctly. Anthropic's engineering guidance on building effective agents shows how much of the quality comes from this kind of detail.
• Reliability mechanics: retries, timeouts, duplicate protection and how webhooks are verified.
• Efficiency: caching, batching and request sizing, as long as the spending ceiling you set still holds.
• Observability: traces, metrics and log formats that let the provider see what the agent did and why.
• Evaluation harness: the test sets and checks that run before and after changes.
• Infrastructure details: servers, queues and storage configuration inside the region and hosting model you approved.

The pattern is consistent. The provider chooses the method, you choose the boundary. If a provider asks you to decide whether to use a particular index type, they are handing you work they should own. If they never mention a change to what data the agent can reach, they are keeping a decision that is yours.

Where does the gray zone sit?

Some settings look technical but carry business consequences. Three come up often.

• Model changes: a different model can change quality, speed and cost, but also which company processes your data and where. That alters your data terms, so it needs your approval even though the provider will make the technical case for it.
• Memory: what the agent remembers across conversations is partly a design choice and partly a privacy choice. Decide what categories of information may be stored and for how long.
• Logging detail: richer logs help debugging but may capture personal data or confidential text. You set what may be recorded and who can read it. Requirements are stricter in regulated settings, as covered in audit trail requirements for regulated companies.

A useful rule for the gray zone is to ask the provider one question: if this setting were wrong, who would be affected outside the system? If the answer includes a customer, an employee, a regulator or your budget, it goes to the business owner.

If a wrong setting could change who sees your data, whom you commit to or what you spend, it is a business decision.

A decision guide: who decides what

Use this three-tier guide when a setting comes up and nobody is sure who owns it.

• Business decides, provider advises: approval rules, data scope, permissions, channels, spending ceilings, external commitments, retention, success and stop conditions, account ownership.
• Provider proposes, business approves: model changes, new tools or integrations, expansion of memory, new data sources, changes to hosting region, changes to logging content.
• Provider decides, business is informed: retrieval tuning, prompt structure, caching, retries, monitoring setup, evaluation methods, routine maintenance within agreed limits.

Print it, adapt it to your agent and attach it to the contract or statement of work, so the tiers are part of the agreement and not a verbal understanding.

An illustrative scenario: a model change that looked technical

This is an illustrative scenario, not a real case. A distribution company runs an order-support agent that answers questions from customers and drafts replies for staff to approve. The provider notices that a different model would respond faster and proposes the switch in a routine update note.

The owner, using the tiers above, sees that the change affects who processes order and customer data. She asks three questions: does the new model's provider keep or train on the data, does processing stay in the approved region, and will the spending ceiling still hold. The provider answers the first two in writing and confirms the third after a short test. She approves, and the switch goes ahead with the approval rule for refunds unchanged.

In the same week the provider also reworks how product manuals are split for search. That change goes out without a meeting, with a note and the results of its evaluation checks. Both changes were handled correctly, by different people, because the boundary was already written down.

How do you set these controls in practice?

You do not need a long project. A small company can complete this in a few working sessions.

• Step one: list the agent's actions, the systems it touches and the people it talks to. This is the raw material.
• Step two: for each action, mark whether it is read-only, reversible or irreversible. Require approval for everything irreversible or customer-facing until the agent has earned more trust.
• Step three: write the data scope as two lists, what the agent may read and what it may write. Anything not on the list is out of scope.
• Step four: set the spending ceiling, alert thresholds and a named person who receives the alerts.
• Step five: name one accountable owner per business setting, and one backup. Settings without an owner drift.
• Step six: agree how changes are requested and approved, and review access on a schedule using a permission review.

Expect the first version to be too cautious. That is acceptable. It is easier to widen access after evidence than to retract it after an incident.

How does Be Human handle this?

Be Human starts an engagement by defining one role for the agent, the memory and tools it needs, the approval boundaries and an observable success criterion, and records those as settings the client owns. The agent runs under its own identity and accounts, with permissions set to that role. During managed operations, the provider handles the technical tuning, monitoring and evaluations, and brings anything that touches data scope, permissions, models or spending to the client as a request to approve. The process is described in how to request and approve changes to a managed AI agent.

Frequently asked questions

Do I need technical skills to control these settings? No. The settings you own are about authority, exposure and cost, which depend on knowing your business and obligations. Your provider should explain each one in plain language and show you what it changes in practice.

Can I change my mind about approvals later? Yes, and you should. Start with human approval for anything external or irreversible, then relax individual rules once you have seen the agent behave well over time. Record each change and who approved it, so the history is clear.

What if my provider says a setting is too technical for me to decide? Ask what happens outside the system if the setting is wrong. If a customer, employee, regulator or budget is affected, the decision is yours, and the provider's job is to explain the options clearly. If nobody outside the system is affected, delegating it is reasonable.

How often should I review the settings? Review them on a regular schedule and after any significant change, such as a new integration, a new team using the agent or a model change. Access tends to grow quietly, so a recurring check of permissions, data scope and spending alerts catches drift early.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.