What should a done-for-you AI agent installation include?
A done-for-you AI agent installation should include workflow discovery, system connections, instructions, permissions, representative tests, deployment, monitoring, documentation, and a named operating owner. The deliverable is not a chatbot or a model subscription. It is a bounded business workflow that can act, stop safely, preserve evidence, and be maintained after launch.
Why is an AI agent installation more than software setup?
An agent does not just generate an answer. OpenAI defines agents as systems that independently accomplish tasks on a user's behalf. They use a model to manage workflow execution, select tools, decide when work is complete, and transfer control back to a person when necessary. That makes installation an operating-design job, not an account-creation job.
A useful provider starts with the work: what triggers it, which inputs matter, which systems the agent must read or update, where judgment appears, what can go wrong, and what counts as done. If that map is missing, the provider may ship a convincing demo that cannot survive the first unusual case. The process should be narrow enough to test and valuable enough to justify ongoing operation.
This is also where a provider should decide whether an agent is needed at all. Anthropic recommends starting with the simplest solution that works because agentic systems can trade additional latency and cost for flexibility. A fixed integration may handle predictable steps. A model may help with one judgment-heavy step. The installation should use autonomy only where the workflow actually needs it.
What should happen during workflow discovery?
Discovery should produce a written map of the current process, not a vague list of features. It should identify the trigger, required inputs, decisions, tools, outputs, exceptions, approval points, owner, and acceptance criteria. It should also separate fixed rules from judgment. Fixed rules belong in deterministic code when possible. Judgment belongs in clearly described instructions with examples and limits.
The provider should inspect the quality of the source data before promising automation. An agent cannot reliably update a CRM if ownership fields are inconsistent, identify a customer if records are duplicated, or follow a policy that only exists in one employee's memory. Discovery needs to expose those gaps because they change the build, the testing plan, and sometimes the decision to proceed.
If you have not selected the workflow yet, use [this process-selection guide](https://gallmur.com/en/notes/how-to-choose-a-business-process-for-an-ai-agent/). A strong first workflow has repeatable value, usable inputs, bounded actions, documented judgment, and a result that a person can verify. 'Help with operations' is not a workflow. 'Review each inbound request, gather missing context, draft a response, and request approval before sending' is.
Which technical pieces should the provider connect and configure?
The installation should connect the systems required by the workflow and no more. That can include a CRM, inbox, document store, calendar, internal knowledge source, messaging channel, or reporting destination. Each connection needs an explicit purpose, a limited permission set, a failure response, and a way to test it without risking live records.
The agent itself needs three foundations: a model, tools, and instructions. OpenAI uses the same three-part foundation in its agent design guide. The provider should select the model for the decisions it must make, expose only the tools needed for the job, and turn the operating rules into instructions the agent can follow. Model choice matters, but it is one component. A stronger model does not repair missing permissions, bad data, weak tools, or an undefined process.
Connections also need state. The system should know which task is running, what has already happened, what remains, and whether an external action succeeded. Without that record, a retry can create duplicate messages, duplicate CRM updates, or work that appears complete when it stopped halfway through. You do not need the provider's private implementation. You do need a clear explanation of how unfinished and repeated work is handled.
What permissions and safety controls should be included?
Permissions should be designed per action, not granted as a broad promise that the agent is safe. Reading a record, drafting a message, sending a message, changing a customer status, issuing a refund, and deleting data carry different consequences. The installation should state which actions run automatically, which need approval, and which are prohibited.
Guardrails are part of the build. OpenAI's guidance describes agents as operating within clearly defined guardrails and being able to halt or transfer control when failure occurs. A done-for-you provider should translate that into the actual workflow: spending limits, allowed recipients, valid record types, retry limits, escalation conditions, and a manual stop path.
Security claims should be concrete. Ask where credentials are stored, who can access them, which external services receive data, what is logged, how long records remain, and what happens when access is revoked. Hermes Agent's public security documentation, for example, describes layered controls for authorization, dangerous-command approval, file writes, isolation, credential filtering, session boundaries, and input validation. The relevant lesson is not to copy one stack. It is to demand named boundaries instead of the word 'secure.'
How should the agent be tested before it touches live work?
Testing should use representative cases drawn from the real workflow. Include normal cases, missing information, contradictory inputs, unavailable tools, duplicate requests, policy exceptions, and actions that require approval. Each case needs an expected result. 'It looked good in the demo' is not an acceptance test.
Microsoft's agent-evaluation guidance recommends establishing a baseline, defining acceptance thresholds, and using criteria tailored to the agent's context. For a business installation, those criteria can include correct tool use, policy adherence, completion, safe escalation, record accuracy, and communication quality. The provider should show what was tested, what passed, what failed, and which permissions remain restricted because the evidence is not strong enough.
Testing also needs a regression set. When the model, instruction, tool, or business rule changes, the provider should rerun known cases before expanding the change. That turns quality from a launch-day opinion into an operating discipline. A reliable installation ships with the cases that protect the workflow, not only with screenshots of successful outputs.
What should deployment, monitoring, and recovery cover?
Deployment should define where the agent runs, how it starts, how secrets and configuration are supplied, and how changes are released. Monitoring should show whether tasks start, finish, fail, wait for approval, or create an external side effect. Alerts should reach a named owner who has enough context to act.
Recovery matters because external systems fail independently. A CRM can reject an update, an email provider can time out, a model can return an unusable response, or a human approval can arrive late. The agent should stop safely, preserve the task state, and expose the recovery step. Depending on the workflow, recovery may mean retrying a safe read, requesting approval again, resuming from a checkpoint, or handing the case to a person.
For a deeper explanation, see [what happens when an AI agent crashes mid-task](https://gallmur.com/en/notes/agent-crash-recovery-durable-execution/). The buying question is simple: after a failure, can the provider prove what happened, what did not happen, and how the task will continue without duplicating the external action?
What documentation and ownership should you receive?
The handoff should include the workflow map, systems connected, permission matrix, approval rules, test cases, known limitations, monitoring path, incident owner, change process, and exit plan. It should name what your team maintains and what the provider maintains. If support is ongoing, define response boundaries and which changes are included.
You should retain control of business data, credentials, operating knowledge, approval policy, and customer records. You should also receive usable evidence of the agent's work: task history, tool actions, outcomes, errors, and evaluation results at a level appropriate to the workflow. A provider may keep reusable platform code, but your business process should not become impossible to understand or move.
This is where managed and self-hosted arrangements can overlap. A provider can operate the system while your business owns the environment and assets. Or the provider can host it while preserving exports and a clean exit. [This managed-versus-self-hosted guide](https://gallmur.com/en/notes/self-hosted-ai-agent-vs-managed-service/) explains the distinction. Outsourcing operation does not require surrendering control.
Which deliverables should appear in the proposal?
A credible proposal should name the workflow, scope, integrations, actions, exclusions, approval boundaries, test plan, deployment environment, monitoring responsibility, documentation, support period, and acceptance decision. It should also state what happens if discovery shows that ordinary automation is the better answer.
Watch for proposals centered on model names, agent counts, dashboards, or a long feature list. Those details can matter, but they do not prove the workflow will operate. The proposal should tell you what business task becomes executable, what evidence confirms it worked, who responds when it fails, and what your company owns after the engagement.
A done-for-you AI agent installation is a transfer of operating capability: a defined workflow becomes executable by a bounded system, with permissions, evidence, tests, and an accountable owner. If the provider cannot describe that transfer before the build, the offer is probably software access with custom setup around it.
Limitations
The exact installation depends on the workflow, data sensitivity, systems involved, legal obligations, expected volume, and consequences of error. A low-risk internal research agent needs different controls from an agent that messages customers or changes financial records. This article is a scope checklist, not a universal architecture.
A complete installation also cannot eliminate the need for human ownership. Business rules change, integrations change, and unusual cases appear. The goal is not permanent autonomy. The goal is a system whose authority, evidence, maintenance, and escalation path remain clear as the work changes.
Map the installation before you pay for the build
Bring one workflow, the systems it touches, the decisions it makes, and the failures you cannot accept. I will help you map what should stay deterministic, where an agent helps, which actions need approval, and what a done-for-you installation must deliver before it goes live.