We Run Duvi on Duvi: The Builder Is Itself an Agent
Our agent builder is itself a Duvi agent on the same runtime. What it writes, where Developer mode takes over, and why dogfooding the runtime is worth its cost.
The thing that builds agents on Duvi is itself an agent on Duvi. Same prompts, same tool interface, same runtime. There is no separate builder engine sitting behind the product.
That was not a clever idea we had. It was the shortest path, and it turned out to be a very effective bug detector.
What it writes
You describe the agent you want. The builder writes the configuration next to the conversation, in four areas:
Identity. Name, system prompt, first message.
Conversation. Chat mode, model, voice, transcriber.
Knowledge. The website addresses to index.
Access. The domains the agent is allowed to run on.
It does not upload files. Files come from your account library and you attach them yourself. That boundary is deliberate: the builder writes configuration, and a file is content. Blurring the two produces an assistant that guesses which document you meant, and being wrong about which PDF grounds your agent is a worse failure than making you pick.
Two doors into the same object
Developer mode is the full surface: Configure, Knowledge, Channels, Preview, Tools, Security, Analytics, Insights, Conversations, Leads. Tools, connectors, customer identity, and the disclaimer live only there.
The part worth noticing is that the builder and Developer mode edit the same agent. There is no import, no sync, no publish step between them. You can describe an agent into existence, open Developer mode, change the exact temperature, go back to the conversation and ask for something else.
This falls out of the builder being an agent rather than a wizard. A wizard owns a draft and hands it over at the end. An agent is just another client of the same API you are, which means there is no draft to hand over and no state to reconcile.
The workflow that emerges on its own: the builder to establish intent, Developer mode for exact values.
Why building it this way was worth it
Running the builder on our own runtime means every weakness in the runtime shows up in the product we use all day.
If tool calling is unreliable, the builder writes bad configuration and we find out in the morning, not from a customer in a month. If context compaction drops something important, the builder forgets what you asked for four messages ago and does the wrong thing in front of us. If the model router fails over badly, the builder stalls while one of us is mid-sentence.
We could have built a purpose-made builder backend. It would have been easier to control, it would have been more predictable, and it would have had its own set of bugs entirely disjoint from the ones affecting customers. Every fix would have helped exactly one of the two systems.
The uncomfortable part
Dogfooding is usually described as if it only produces benefits. It also produces a specific pressure that is worth naming.
When the builder misbehaves, there are two available explanations. The configuration it wrote was wrong, or the runtime underneath it did something wrong. Those have very different fixes and they look identical from the outside: an agent that did not do what you asked.
So a meaningful share of our debugging starts by working out which layer failed. That cost is real and it is the price of the arrangement. What you get for it is that neither layer can quietly rot, because both are load-bearing for the thing we open every day.
The claim it forces us to keep
There is a sentence we would like to be able to say, which is that launching an agent takes no engineering work.
The only honest way to be able to say that is for the people writing the engineering to build their agents the same way a customer does. Not a demo account, not a seeded fixture, not a staging tenant with special privileges. The same builder, the same runtime, the same four configuration areas, the same limits.
If it were easier for us than for you, we would not know. That is the actual argument for running your product on your product, and it is not really about finding bugs. It is that you cannot make a claim about an experience you have arranged not to have.