Build, Buy or Manage AI Agents: Who Maintains What Over Time

Build, buy or manage is mostly a question about who will keep an AI agent correct after launch. Building gives you full control but makes your team the permanent operator. Buying a packaged product starts quickly, but its permission model, memory handling and integration logic usually stay on the vendor's terms. A managed agent layer splits the work: you keep the business decisions and approvals, while a specialist operator runs monitoring, evaluations and maintenance under written boundaries.

Key takeaways

• The first demo rarely decides the right option. The recurring work of permission review, memory upkeep and integration repair does.
• Build, buy and managed options differ mainly in who holds the operating role after go-live.
• Name an owner for four things before comparing options: permissions, memory, integrations and evaluation.
• Write the split of responsibilities down, with an approver and a record for every change.
• Choose the option where the named maintainer can still run the agent safely several months after launch.

Why maintenance decides the choice

An AI agent is not a document you write once. It reads from data sources, calls tools, holds context and depends on external services that change their interfaces without much notice. Each of those parts drifts. A person who changed roles still has access. A tool description no longer matches the API it wraps. Stored memory contains an outdated price list or a customer detail that should have expired. A model update quietly changes how the agent handles a question it used to answer well.

The NIST AI Risk Management Framework treats AI risk as something managed across the whole lifecycle, not only at design time. That is a useful lens for this decision. Ask less whether you can build the agent and more who will govern, measure and manage it in the twelfth month. Most regret in agent projects comes from that gap, not from the initial build.

The three options, described by who maintains what

Building means your engineers or a contractor own the whole stack: model integration, retrieval, tool wiring, the evaluation harness and hosting. You gain control over every boundary and can shape the agent around your processes. The cost is that you need people who understand agent design, security and evaluation, and they need time reserved every month for upkeep. The usual failure is not the launch. It is the moment the builder moves to another project and nobody can explain why the agent holds the access it has.

Buying a packaged product or platform shifts the platform work to the vendor. Setup is faster, and the vendor maintains the underlying software. What stays with you is the business logic: which actions the agent may take, which data it may see, and what happens when a rule changes. Check how much of that logic can be exported. If your rules, memory and permission definitions exist only inside one interface, switching later becomes a rebuild. The steps for reducing that exposure are covered in how to avoid AI vendor lock-in with business agents.

A managed agent layer means an operator takes on a defined maintenance role under agreed boundaries. The typical scope covers monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. You keep ownership of the outcome and the approval decisions. The operator keeps the agent running and reports what changed. This suits companies that want a dedicated agent without building an internal platform team, but it only works if the boundaries are written and the approvals are actually exercised.

Map who maintains each part over time

Four components need an owner after launch. Treat them separately, because each one drifts at a different pace.

• Identity and instructions: the agent's role, tone, scope and escalation rules. Review them when the business process changes, and approve every edit.
• Memory: the information the agent retains and retrieves. Review what is stored, remove what is stale or sensitive, and confirm who may add to it.
• Tools and integrations: the systems the agent reads from or writes to. Monitor API changes, credential expiry and failed calls.
• Permissions: what each tool may do, for which users, under which conditions. Apply least privilege from the start and check it on a fixed schedule.

Retrieval-based designs make the memory point concrete. The agent answers from a document store, so the quality of that store sets the quality of the answers. The OWASP Authorization Cheat Sheet recommends denying access by default and granting only what a function needs, which maps directly to the permissions component above. A structured review of those grants is described in the quarterly AI agent permission review. For observability, the OpenTelemetry concepts primer describes the kinds of signals a maintainer should be able to see: traces of agent actions, errors and latency, not only the final answer.

A step-by-step plan for choosing

Use this sequence before you request proposals or start a build. It takes a working session, not a long study.

• Step 1: Write the single role you want the agent to perform, in one sentence, with the users it serves.
• Step 2: List every system it must read from and every action it may take, marking the actions that change data.
• Step 3: For each marked action, name the person who approves it and the person who revokes access when that person leaves the company or changes roles.
• Step 4: Define how success will be observed, such as a measurable outcome in the process the agent touches, and who checks it each month.
• Step 5: Assign an owner for memory, integrations and permissions, and state whether that owner is internal, the vendor or an operator.
• Step 6: Score each option against those owners. If no option has a named owner for a component, that component is not ready to be automated.
• Step 7: Choose the option where every component has an owner and a review cadence your team can sustain.

Illustrative scenario: a supplier question agent

Illustrative scenario: a small operations team wants an agent that answers supplier delivery status from the order system and drafts replies for a person to send. A build option would need an engineer to maintain the order system connection and the evaluation questions after launch. A packaged tool would be quick to start, but its permission model might grant write access to orders when the team needs read-only access. A managed layer would begin with read-only access, a written rule that any draft changing a delivery commitment needs human approval, and a monthly permission review. In each case the question is the same: when the order system changes or a team member leaves, who acts, and how is the change recorded?

How Be Human handles the maintenance split

Be Human designs and operates personalized AI infrastructure for companies, with agents that keep their identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with changes requested and approved in writing. The service is remote and available in English and Portuguese. The client remains the approver for business decisions, and the operator carries the recurring technical upkeep.

Questions to answer before you sign anything

Whichever option you lean toward, ask for written answers to these questions. The AI agent statement of work checklist shows where each answer belongs in a contract.

• Who holds administrative access to the agent, its tools and its memory, and how is that access removed?
• Can memory, instructions and permission definitions be exported in a readable form?
• What happens to the agent when a connected system changes its interface or a vendor changes its terms?
• What evidence will you receive each month, such as evaluation results, incident records and permission changes?
• Who approves a change, how is it recorded, and how long does a rollback take?
• How does the agent stop if you decide to end the work, and what is kept or deleted?

If you are not yet sure which workflow should go first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Is building an AI agent in-house always cheaper than buying one? No, not necessarily. Building avoids platform fees, but it adds the salary, attention and time of people who must monitor evaluations, repair integrations and review permissions every month. Compare the full recurring workload with the vendor or operator alternative before deciding on cost.

When does buying a packaged AI tool make sense? It fits when the workflow is common, the data is not unusually sensitive, and you can export your rules and memory if you leave. Confirm who controls permissions and how changes are logged. If the tool cannot show those things, treat it as a pilot rather than as long-term infrastructure.

What does a managed agent layer include beyond the initial build? Typically it includes monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The operator runs these under boundaries you approve. You still decide what the agent is for, which actions it may take and when a change goes live.

Who should own the agent after launch? Ownership of the outcome should sit with a business leader, because that person decides whether the agent is doing useful work. Technical maintenance can sit internally, with a vendor or with an operator, but each component needs a named person and a review rhythm. An agent without a named owner usually drifts until someone notices a failure.

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