Deltastring agent FAQ
Direct answers, no hedging. If you have a question that isn't here, ask. We'd rather answer it now than have it surface in the contract review. For the longer architectural argument, see Why you don't want a direct-to-Zendesk MCP.
Isn’t this just another AI tool to lock down?
The opposite. Your team is using AI with your business systems right now. Deltastring’s agent isn’t introducing AI to your Zendesk. It’s giving the AI use that’s already happening a sanctioned, audited, governed path. Without Deltastring’s agent, someone on your team will paste an API key into a chat conversation to get a job done, and you won’t know they did. With Deltastring’s agent, the credential lives in Deltastring, the action goes through your existing approval flow, and the audit trail is your existing audit trail.
The right question isn’t “should we allow AI near our Zendesk”. The AI is near your Zendesk. The right question is “is the path it’s taking a path we approved”.
Can the AI break my Zendesk?
No. The AI assistant your team uses cannot reach Zendesk. The Deltastring agent has no Zendesk credentials. It talks to Deltastring. Deltastring talks to Zendesk. Read calls don’t even hit live Zendesk: the agent reads Deltastring’s most recent configuration snapshot.
For sandbox changes, the agent can apply directly through Deltastring after the user confirms in-flow. For production changes, the agent has no apply path at all. It returns an approval link to Deltastring’s web app, and a different, named human approves the change there. The agent cannot push to production. That boundary is enforced in the route, not in policy we promise to follow.
Who can approve changes to production?
Anyone in your team with editor access to the target Zendesk connection, except the person who asked. Self-review is blocked. The asker and the approver have to be different people. The asker can be a team member working through an AI assistant; the approver has to log into Deltastring’s web app and click Approve themselves.
Sandbox changes don’t need an approver. That’s where your team experiments.
The plan link expires after 72 hours by default. If nobody approves, it lapses, and the agent has to produce a fresh plan to try again.
What happens if a change goes wrong?
Every applied change comes back with a rollback token. The token holds the full before-state of every object the change touched. One click reverses the change exactly. You’re not relying on a best-effort undo.
If the apply fails partway through, Deltastring records what succeeded and what didn’t. You can retry just the failed parts, or roll back the whole thing.
How do I know what the AI did?
The audit log. Every plan the agent proposes, every plan you approve, every plan you reject, every apply that runs, every rollback that runs. All of it in Deltastring’s audit trail, with the actor, the timestamp, the request, the plan, and the result.
There isn’t a separate AI log. The agent’s changes are in the same log as everyone else’s, because the agent uses the same path as everyone else.
Can the AI assistant see customer data in tickets?
Not through Deltastring’s agent. The agent is about configuration: triggers, automations, views, groups, fields, forms. It doesn’t read or expose ticket content.
If you want an AI assistant to read tickets, that’s a different product. Zendesk’s own AI features are built for that. Deltastring isn’t.
Can the assistant create users and organisations?
Yes. Through the MCP you can create and update users and organisations, and run bulk changes like tags, group and organisation membership, and user fields. Each one is previewed, goes through the same approval step as any other change, and can be undone.
What Deltastring doesn’t do is pull or store user-level data. It acts on your instance in the moment and keeps only what’s needed to reverse the change, not a copy of your people or their personal details. It can also reference an existing organisation or user by id where a rule or field needs one. Reading and holding your customer records is a different job, and not this product’s.
What stops a malicious or compromised AI from doing damage?
Three things, in order of importance.
The agent has no Zendesk credentials. There is no token to steal, no cookie to abuse, no path that doesn’t go through Deltastring.
Deltastring’s approval gate. A compromised assistant can ask for whatever it likes. Production won’t apply until a named human approves. The asker and the approver are different.
The audit trail and rollback. If an approved change was wrong, you see exactly what happened and you reverse it.
The question to ask vendors of every AI tool in your stack: “what does this tool have access to that I haven’t seen?” Deltastring’s answer is “nothing it could use without going through Deltastring and through you”.
What AI assistants does it work with?
Any AI assistant that supports MCP, the open Model Context Protocol. In practice that means any MCP-compatible assistant, such as Claude, and the list grows as more tools adopt MCP.
We don’t tie the product to a specific vendor. You bring whichever assistant your team already uses or trusts.
What if our security team won’t allow AI tooling at all?
Then don’t use the agent interface. Use Deltastring’s web app. Deltastring works without the agent. The agent requires Deltastring.
If your security team’s concern is specifically about AI tooling that can change configuration, the Deltastring-with-agent story is the answer to that concern, not a thing for them to worry about. The architectural boundary is the point of the product. We’d be happy to walk a security team through it.
What does this cost?
The agent interface uses Deltastring’s engine, so it isn’t a standalone product. Whether it’s bundled into your existing Deltastring tier, sits on a higher tier, or is an add-on is being decided. See the pricing page. Free trial available, no card needed, only the days you actually use it count.
What happens to our data?
Configuration data only. Deltastring doesn’t read ticket content. Configuration snapshots are encrypted at rest, encrypted in transit, scoped per customer. The agent does not retain conversation content from your AI assistant. The audit log retains what the agent asked Deltastring to do, not the assistant’s wider conversation history.
Full data handling details are linked from the Deltastring page footer. Happy to send the DPA in advance for procurement review.
Are you going to start using our configuration data to train AI?
No. We don’t train models. We don’t sell data. The configuration belongs to you. The agent uses your AI assistant’s model on your account, not ours.
What changes for our admins day-to-day?
The admins keep doing what they’re doing in Deltastring. The change is that the rest of the team can now ask the agent for things the admins used to be the only people able to do, with the admins still in the approval seat for production. The bottleneck where every config change waits on the admin gets smaller. The admin’s role moves toward reviewing and approving rather than clicking through admin panels.
The admins generally like this. They get more time to do the work that needed them in the first place.
Start the trial, see the Deltastring overview, or read why a direct-to-Zendesk MCP is the wrong shape.