If Your Team Can't Change the Agent, You Don't Control It
Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built for them by vendor engineers. Before someone builds yours, find out whether your team can change it, see what it did, and keep its history if you leave.
Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built for them by vendor engineers. Before someone builds yours, find out whether your team can change it, see what it did, and keep its history if you leave.
Gartner predicts that by 2028, 70% of enterprises will abandon AI agents built for them by vendor engineers. Its warning is about what happens after launch: rising costs and systems customers can't evolve on their own.
That caught my attention because Civic spent years building custom solutions for customers. We could solve the original problem, but the harder work often came later, when the customer needed to change the system. Too often, they still needed us to do it.
We moved away from that model this year. And the experience left me with three questions I would ask before hiring anyone to build an AI agent.
When hiring engineers to build an agent makes sense
Gartner describes the model as one "in which vendor engineers work directly with customers to build and deploy solutions." The appeal is easy to understand. You get experienced engineers working directly with your team on a problem they understand, and early progress can be fast.
Gartner doesn't say the model is wrong. It says to use it "only for problems that require deep product expertise, rapid adaptation, or close integration between vendor technology and your operating environment." Some problems really are like that.
BUT, before hiring those engineers, find out who will maintain the agent after they leave.
The real test begins after launch
An agent isn't finished when it goes live. The work it does keeps changing because your business keeps changing.
You discover that a new type of customer is buying more often, so you change who the agent should target. Marketing rebuilds the pricing page. You launch a product, and a new kind of buyer starts showing up. A new rep joins and needs alerts for their territory. Each change requires someone to update the agent's rules.
If those changes require the vendor's engineers, your team submits a request, waits for the change, and may have to pay for additional engineering time. That's how the cost Gartner describes builds up: one reasonable change request at a time, for as long as you keep the system.
When the original engineers move on, the people who understand the system may be gone. Unless that tribal knowledge was written down and handed over, your team inherits a system it can use but can't confidently change.
Gartner also predicts that through 2028, fewer than 20% of these engagements will turn recurring customer needs into features of the vendor's main product. That raises another question for buyers: will your implementation benefit from future product improvements, or will it remain a separate system that needs its own maintenance?
We saw this ourselves at Civic. We could build a solution that worked, but customers still needed changes after launch. Sometimes the person who understood the original implementation was no longer available, or the customer needed us to make an update they couldn't make themselves. We learned that a successful launch meant very little if the customer couldn't maintain the system afterward.
Three questions to ask before someone builds an agent for you
If you're considering an agent that a vendor's team will build and deploy, these three questions get you most of the way there.
Can your team change it without the vendor? Can your team see what it did? Can you leave the vendor and keep the history?
Can your team change it without the vendor? During the demo, ask someone from your own team to change a targeting rule or redirect an alert. Watch whether they can do it without calling an engineer. Also ask how changes are tested and approved before going live. If your team has to submit a support ticket for an ordinary change, find out how long that will take and what it will cost.
Can your team see what it did? Ask to see the record of a real agent action. You should be able to find what triggered it, which rule was applied, what action the agent took, and who approved it if approval was required. Ask whether your team can search and export that information without vendor assistance. Gartner recommends using each stage of an engagement to "define decision rights" and set "the appropriate balance between autonomy and human oversight." That's hard to do if only the vendor can read the record.
Can you leave the vendor and keep the history? Gartner's advice here is direct: agree on knowledge transfer, intellectual property rights, and "transition or exit responsibilities" before you sign, and then "execute the exit plan established at the start rather than extending the engagement because internal teams are not ready." Before signing, ask what you can take with you if you switch providers. That includes your data, the agent's activity history, and any rules or configurations you own. Ask for a sample export and find out whether the information will be usable in another system. Keep in mind that exporting an activity history is different from moving a working agent to another platform.
Here's the question I'd ask in every agent evaluation:
If the vendor's engineers left tomorrow, could your team keep running it?
If the answer is yes, a vendor's engineers can be a fast way to get started. If the answer is no, most future changes to the agent will depend on the vendor, and so will the ongoing cost.
WHO MAKES THE CHANGE AFTER GO-LIVE?
Choose a situation that could come up after your agent goes live. See the difference between relying on the vendor and managing the agent yourself.
This tests: Can your team change it without the vendor?
Your targeting changes
CHANGES DEPEND ON THE VENDOR
Your team requests changes and relies on the vendor to make them.
Your team requests an update. The vendor changes and tests the targeting rules. Timing and cost depend on your contract.
YOUR TEAM MANAGES THE AGENT
Your team can make supported changes directly, with appropriate permissions.
An authorized member of your team updates the targeting rule, tests it, and publishes the change.
This tests: Can your team change it without the vendor?
CHANGES DEPEND ON THE VENDOR
Your team requests changes and relies on the vendor to make them.
Your team requests an update. The vendor changes and tests the targeting rules. Timing and cost depend on your contract.
YOUR TEAM MANAGES THE AGENT
Your team can make supported changes directly, with appropriate permissions.
An authorized member of your team updates the targeting rule, tests it, and publishes the change.
This tests: Can your team change it without the vendor?
CHANGES DEPEND ON THE VENDOR
Your team requests changes and relies on the vendor to make them.
Your team asks the vendor to change who receives the alerts.
YOUR TEAM MANAGES THE AGENT
Your team can make supported changes directly, with appropriate permissions.
Your team adds the new rep, updates who receives the alerts, and checks that the rule works.
This tests: Can your team change it without the vendor?
CHANGES DEPEND ON THE VENDOR
Your team requests changes and relies on the vendor to make them.
If the engineer didn't document how the agent works, their replacement may need time to understand the system before making changes.
YOUR TEAM MANAGES THE AGENT
Your team can make supported changes directly, with appropriate permissions.
The agent's rules and change history remain available to authorized team members, provided the system supports that access.
This tests: Can your team see what it did?
CHANGES DEPEND ON THE VENDOR
Your team requests changes and relies on the vendor to make them.
Your team asks the vendor for a record of the agent's actions and any approvals. What is available depends on the logging included in your agreement.
YOUR TEAM MANAGES THE AGENT
Your team can make supported changes directly, with appropriate permissions.
Your team reviews the activity and approval history and exports the report. It checks connected systems to confirm what happened after the agent initiated an action.
This tests: Can you leave the vendor and keep the history?
CHANGES DEPEND ON THE VENDOR
Your team requests changes and relies on the vendor to make them.
Your contract determines what rules, data, history, and transition support you receive.
YOUR TEAM MANAGES THE AGENT
Your team can make supported changes directly, with appropriate permissions.
Your team exports the available records and configurations. You may still need to rebuild the agent in another product.
Don't just ask for a demo. Ask to make a change yourself.
Then ask to review the agent's activity history and see what you can export if you leave.
Examples are illustrative. Capabilities and contract terms vary. Gartner recommends agreeing on knowledge transfer, ownership rights, and exit responsibilities before signing (Sept. 29, 2026).
Why we built Bryn differently
We built Bryn so growth teams can manage their own AI workflows without relying on Civic engineers for everyday changes. That's the model we chose when we stopped doing custom work, and it's how Bryn answers each question.
Can your team change it without the vendor? Your team defines the approved workflows that decide what happens when a buyer shows up on your site, which Bryn calls Plays, and edits them in the product. When your targeting changes, your team can update the supported rules directly in Bryn, review them, and put the change into use. Because Bryn is a shared product rather than a separate custom build for each customer, product improvements can reach customers without individual rebuilds.
Can your team see what it did? Bryn records every run. Authorized members of your team can review the activity history or export it for finance and compliance. Bryn records what triggered an action, why it ran, and what Bryn initiated. The connected CRM, email tool, or other platform is where you verify what happened afterward.
Can you leave the vendor and keep the history? Bryn bills monthly on every plan, with no contract minimums, and the audit log can be exported at any point, including when you leave.
Our largest plan includes onboarding help. That help sets up the product your team will run. It doesn't create a separate system that only we can change.
Choose the agent your team can keep running
Some companies will need engineers to build highly specialized agents. That can be the right decision, provided the customer understands what happens after those engineers leave.
Before choosing an agent, have someone on your team make a routine change, inspect the activity history, and ask for an export of the records.
A working demo tells you the agent can launch. Those three tests tell you whether your team can live with it.
BRIEFS ⬩ PUBLIC PREVIEW
Next: a Brief on your own site.
Bryn reads your site and works out which companies are already looking at you, and whether they're worth your time. Then it writes up the first follow-up it would run, in your own colors, inside a minute. It takes a few minutes to read. Then pass it to whoever signs off.
