The agent writes a good answer. Then someone copies it into Salesforce, checks whether the account details are current, and asks a colleague whether the promised discount is allowed. The expensive part still waits for a human.

A different agent can improve the answer and leave every handoff intact.

Start the buying decision with the point where work stops. The gap is a better agent, access to a system, a reusable method, or an approver. Each is a different purchase with its own owner and maintenance cost.

This guide is the first step in Choosing and rolling out agents; evaluate the shortlist against real tasks next.

What problem are you buying a solution to?#

Pick a recent task that almost worked. Follow it from request to business result and mark the first place a person had to intervene and what they supplied.

What happened	What was missing	What to evaluate
The agent misunderstood a clear request	Task interpretation or planning	Agent behavior on representative work
The answer was useful but based on old account details	Access to a current source	Retrieval, connector access, and source freshness
The agent repeated a correction from last week	A reviewed lesson that future tasks can use	Memory review, scope, editing, and reuse
The agent found the answer but someone pasted it into another app	An action and a reliable handoff	Tool operations, permissions, and confirmation of the result
The agent asked for permission on every harmless step	An overly broad approval rule	Rules that distinguish routine work from consequential actions
Nobody could explain why the task ran repeatedly	A readable action history	Task identity, tool calls, retries, and cost attribution

A workflow can have several gaps. Rank them by the work they create; a duplicate customer email outranks a missing diagram generator.

Before meeting vendors, write one sentence: “We need our existing agent to prepare a renewal using current account information, produce a draft, and wait for the account owner before sending.” It gives the conversation a finish line.

When should you buy another agent?#

Buy an agent when task execution is the problem: it cannot follow the method, use the available tools sensibly, or produce work the team can accept. Buy one also when the team has no agent today.

Have the agent handle a messy version of your task: an ambiguous account name, conflicting notes, and a request outside its authority. Watch what it asks, assumes, and does after correction.

A polished answer is evidence about writing, not about finishing work. Include the final destination in the trial: the issue created, draft saved, record updated, or handoff accepted by its next owner.

A model selector is no evidence that you can keep your current agent. Ask separately whether your existing runtime can call the vendor’s tools and whether your team must move its workflows into a new interface.

When is connecting the existing agent the better move?#

Keep a capable agent when its failures come from missing company information, disconnected tools, or unclear permission to act. Replacing it repeats setup and training, and the gaps remain.

Evaluate the connection at the operation level. “Salesforce integration” does not say whether the workflow can read the right account, create a note, update a field, or respect your permissions. Walk through each required read and write.

The connector catalog is a starting point. For a concrete example, trace a Salesforce and Stripe account brief: which system owns the account facts, what gets shared in the conversation, and what must make it back into the account record?

Also draw the path around the connection. If an agent reaches the same system through a separate credential, controls on one route do not govern the other. Ask which calls pass through the control you are evaluating and how the action history shows it.

What is worth building yourself?#

Build the part that expresses how your company works: a proprietary decision method, a specialized user experience, or a workflow central to your product. Keep it small enough for a named team to operate.

Buy the surrounding components when maintaining authentication, provider changes, tool schemas, and operational history would pull that team from its distinctive work. Someone still configures access and responds when a connection breaks.

Compare the options in a design review:

Decision	Build	Buy	Connect existing tools
Main reason	Unique behavior is central to the business	A repeatable need is well served by a product	The agent works but lacks context or actions
Team must own	Implementation, operation, and changes	Configuration, supplier relationship, and workflow acceptance	Integration boundaries, permissions, and handoffs
Trial should expose	Maintenance work after the first successful run	Fit on your tasks and limits outside the demo	Exact operations, failure handling, and result visibility
Exit question	Can another engineer operate it?	Can we export the work and change suppliers?	Can we replace one connected component without rebuilding everything?

The approaches combine: build a specialized investigation agent, connect company systems through Deixic, and use a purchased app for the human review screen. Evaluate the complete path.

What costs belong in the comparison?#

List the work the team performs today and after adoption, including setup, migration, review, administration, and repair. A cheaper subscription can leave a costlier workflow. Use inspectable units:

Completed tasks per period, separated by task type.
Provider and tool charges associated with those tasks.
Time spent reviewing, correcting, and finishing the results.
Time spent maintaining credentials, permissions, and integrations.
Work needed to migrate or leave the product.

Keep one-time implementation costs separate from recurring operating costs, and start with the task types the trial covered instead of scaling a demo result to the whole workload.

The cost-per-finished-task guide compares tasks when one option uses fewer model calls but creates more human cleanup, which matters most when pricing units differ across shortlisted tools.

What should you ask about portability?#

Ask what survives if you change the model, agent, or vendor. Name what you expect to retain: source documents, reviewed corrections, procedures, approval history, completed artifacts, and their relationships.

Ask for a sample export and have someone read it: can they identify the task, source, owner, and result, and can a different tool use the procedure?

Separate reusable knowledge from task chatter: retain a reviewed renewal procedure without promoting every tentative answer into company memory. Ask who approves that distinction and who can correct it later.

How Deixic fits the decision#

Deixic executes SOC 2 work for growing companies: fixes failing controls across connected systems within the authority you grant, verifies changes, and keeps the evidence. Its existing-agent path lets your agents read the same access, change, and receipt records over MCP. Changes routed through Deixic follow the same policy and approval rules. Dex is the optional agent for teams that need one.

For a demo, bring a failing SOC 2 control and ask to see the setting changed, the named approval, and the read-back evidence.

What should the shortlist contain?#

Keep a short decision record for each option, in the document your team already uses:

Task and business result:
First point where the current workflow needs help:
What we will keep:
What this option replaces or adds:
Required system reads and writes:
Who configures and maintains it:
Who reviews consequential actions:
What useful knowledge survives the task:
What we can export:
Open questions to resolve in a trial:
Reason to reject this option:

If keeping your agent is essential, an option that requires replacing it leaves the shortlist early. If the work needs an operation the connection cannot perform, a long catalog of other integrations does not fix that.

Next, run the task-based evaluation.