Specify it yourself, with no engineering team to book. Live in weeks, in your own infrastructure under your own brand.
A business electricity portal: the agent explains an 18 % bill rise across three restaurant sites, and shows which site produced the peak-hour cost.
Build
Focus on building your solution.
A studio user asks Intentface Studio for a billing agent that answers customers' questions about their electricity bill, and attaches the company's tariff terms and the OpenAPI spec for its consumption data. The studio reads both, takes on the company's colours, and opens a branded agent she can talk to, with the studio's tools beside it: Brand, Layout, Connections, Prompt, Knowledge, Models and Artifacts.
State of the art UI
Streaming, tool calls, approval prompts, retries and file handling already exist as components. Set them up, send a design guide, and the interface wears your brand within hours.
The agent backend
Conversation history, durability, scheduling, approvals and per-tenant isolation, already running in production and maintained for you.
Knowledge layer
Policies, procedures, pricing and playbooks live in a workspace your own team edits. That workspace is the agent's context, and a wording change takes effect as soon as they save it.
Iterate
Start with a small group of real users.
Manage users and access
Invite a team, a segment or one pilot customer, and expand the group when you feel confident. Access is yours to grant and revoke at any point.
Collect production traces
Every turn is tagged with tenant, user and agent, so you can see where the agent guesses and where users give up. The result is a ranked list of what to fix.
Improve it from what you learn
Turn the failures you find into context edits and tool fixes. Each round raises the quality of the next, and everything you learn stays in your own system.
Integrate
Build in Studio, deploy in your own infrastructure.
Hosted in your cloud
Build it in Studio, then deploy it to your own cloud whenever you want. Your users' data stays inside your own systems, so the security review stays short.
Signs in with your own login
Studio connects to the identity provider you already use, so users sign in the way they always have. The agent then acts as that person, with the permissions they already have.
Writes only with permission
Credential vaults, tenant isolation and approval gates come with the platform. You decide which actions the agent can take on its own, and which ones it has to ask about first.
The agent has read the contract and the consumption, drafted a renewal price query for the sales team, and stopped to have it approved before sending.
Connect
Connect your agents to your data.
Connected once, by an admin
A connection is a URL and an access grant, set up once. Nobody else on your team has to connect anything or keep an account of their own.
No API, no MCP?
No problem. Building a connector is a smaller job than it sounds. Do it yourself, or have it built for you, the way it has been for other clients. See the work
Start before anything is connected
You can build and specify the agent first. Questions about policy, process and how something works run on the knowledge layer, so they ship before a single system is wired up.
Four connected systems, each reached over MCP or an HTTP API: customer records, billing, metering and spot prices.
Questions
What do we need to have in place before we start?
Nothing, to start. A vertical expert that answers on your policies, procedures and pricing runs on the knowledge layer alone, and that covers a good half of what people actually ask. If you want the agent working on your own data too, the recommendation is one declared surface it can reach: an MCP server or an OpenAPI spec. Building one is a smaller job than it sounds, and it can be built for you.
Where does it run, and who holds the data?
It is hosted in your cloud, inside your own service boundary, and self-hosted from the start. Your users' data stays in your systems, which keeps the security review short.
Do our users need a second login?
No. Your app owns login and Studio trusts the identity you hand it, so the person who signed in to your product is the person the agent acts for.
Can the agent write to our systems?
Yes. It reads freely and asks for confirmation before it writes. Per-tenant credential vaulting, tenant isolation and approval gates cover anything consequential, and building that layer properly is most of the work in taking an agent to production.
Who keeps the agents up to date?
The people who own the knowledge. Policies, procedures, pricing and playbooks live in a workspace your team edits directly, and a wording change takes effect as soon as they save it.
How do we know whether it's working?
Every turn is traced: prompt, tools, results, latency and cost, tagged with tenant, user and agent. You can see where the agent guesses, where it stalls and where users give up, which gives you a ranked list of what to fix next.
What happens when we want it inside our main app?
It moves, and nothing is rebuilt. The agents, the tools and the login come with it. The only thing that changes is where the interface renders.
What does it cost, and how long is “weeks”?
Both depend on what you bring. An existing MCP server and a written policy set move fastest; a surface scoped from scratch takes longer. That gets worked out on the call rather than guessed at here.
Embedded when you're ready.
One 30-minute call to see whether it fits.