The Model Is an Actor, Not the Company
Every interesting lesson we have learned about customer-facing AI has come from a public failure. The most humbling pattern is watching an agent that handles internal tests perfectly ten times in a row, then says something confidently wrong on a live call with a prospect. Our first instinct, like everyone's, was to open the system prompt and try to talk the model out of its bad habits. That fix never held. The prompt was not the problem. A prompt is advice, and advice does not stop an actor from wandering off stage.
What separates an agent from a chatbot is agency in a specific context. A chatbot answers. An agent answers, then acts on the answer, then remembers what it did, then decides whether it needs a human. To act, the agent needs tools, permissions, a record of the conversation, and a clear definition of what it is allowed to do with each resource it touches. None of that lives inside the model weights. None of it lives in a single text block. It exists in the environment you build around the model, and that environment is a product decision.
We started building Seminara with the usual framing: we were making a smarter bot that could run a demo. The first versions failed the way all bots fail. The agent could answer questions, but it could not drive the product. It could not share its screen in the right order, could not stop talking when the buyer needed a beat to think, and could not recover when it made an error it could not explain. We were not building a teammate. We were building a distraction with a friendly voice.
The conversation in the AI world keeps circling back to context windows as if the model's input limit were the bottleneck. For a customer-facing agent, the real context is the business state: where the deal stands, who is in the room, which claims are approved, which questions must escalate to a human. That state has to live somewhere outside the chat history. The environment is the company's official record of what the agent did, said, and promised. Without that record, the agent is performing in a vacuum and the company is blind.
The Environment Enforces the Contract
Watch a good sales representative for an hour and you will notice how much of their behavior is governed by the room they are in. They have a sequence for the first ten minutes. They keep a list of approved numbers they can quote. They know which claims need legal sign-off and which questions should be handled after the call. They know a demo is not a lecture, a pitch is not a training session, and a buyer who is talking is a buyer who is close. None of that knowledge is supernatural. It is institutional memory, and the representative could not do their job without it.
An AI agent cannot absorb that memory through a chat window. It needs an environment that makes the company's constraints hard to violate. This is the difference between a helpful bot and a representative. In one design, the model receives a long list of instructions and is asked to be careful. In the other, the model operates inside a workspace where the instructions are enforced by structure. If the agent lacks the tool to send an invoice, it cannot invoice the wrong amount. If it has no access to the internal database, it cannot hallucinate a customer count. The system prompt sets the tone. The environment sets the law.
We learned this by making the opposite mistake. Our early customer-facing agents had broad access to our internal notes and every tool we owned, and they used all of it at the wrong moments. An agent trying to answer a pricing question would pull up a product roadmap. An agent running a demo would jump to a feature the prospect had never asked about. The fix was not a cleverer system prompt. It was a process of removal. We asked what a representative needed to complete a specific job, not what a general assistant might want, and we stripped away everything else.
A prompt is advice. An environment is a contract.
The term system prompt has become a shorthand for the agent's rules, as if the whole discipline of agent building were a matter of writing better instructions. In practice, the rules that matter are the ones you can enforce without asking the model to be polite. Enforcement requires a runtime. The model must not be able to reach outside the boundaries you set, and the boundaries themselves must be checkable by the company before the agent ever talks to a customer.
What Running a Live Demo Taught Us About Software
Live product demos are a terrible experience for everyone involved. The buyer has sat through dozens of them and expects to be talked at for an hour. The rep is fumbling between tabs and praying that the local environment does not break mid-click. The founder is doing the demo because there is no one else to do it, and the founder's voice cracks on the introduction. Most teams treat no-shows as a calendar problem, but what we saw was a trust problem. A prospect who does not believe the meeting will teach them something new finds a reason to skip it.
Seminara exists because we think the demo is not the moment where you prove the product. It is the moment where you prove you understand the buyer's problem, and the product is the evidence you lay out in support of that understanding. An agent that runs a demo is therefore not an automated presentation tool. It is a host. It has to open the product at the right time, zoom in on the relevant feature, stop when it sees uncertainty, and ask whether the buyer has seen something similar. It has to adapt to an off-script question without losing its place. It has to know when to hand the conversation to a human.
We built the hosting environment to make those moves possible. The demo sequence is broken into stages, and each stage carries the state of the session so the agent always knows what it has shown and what it has promised. If the agent gets tangled, the environment catches the confusion before the buyer does. If the buyer asks a question the agent is not authorized to answer, the environment offers a clean handoff to a human rather than letting the agent improvise a vague response. The prompt matters far less than the playing field.
Live demos are the sharpest test for this kind of system because the cost of failure is immediate and public. A chatbot can be corrected with a follow-up message. An agent that says the wrong thing in front of a qualified buyer plants a doubt that no polite email can remove. We built a workspace where the agent's range is bounded, where retries are automatic, where every action is logged, and where a human can step in with a single control. The result feels less like watching a robot talk and more like watching a careful colleague who has done this a hundred times.
Reliability Is Boring by Design
Ask any founder who has put an agent in front of a customer what keeps them up at night, and the answer will not be about model quality. It will be about the agent doing something unaccountable in the uncontrolled middle of a conversation. This is why we treat reliability as an environment problem, not a prompt problem. A prompt can be evaded, either by the model's confusion or by a user's manipulation. An environment that does not offer a dangerous action cannot be evaded, because the action does not exist.
Consider idempotency. When a human sends an email, they send it once and move on. When an agent has tool access, it might retry an action because it did not see its own confirmation, and then the prospect receives three identical follow-ups. The agent was not trying to annoy anyone. The environment failed to make the outcome of an action visible and repeatable. We now treat every tool call in the workspace as an operation that can be safely retried or explicitly declined, and we made the confirmation step something the agent cannot skip.
Then there is prompt injection. Internal instructions leak. A prospect can type commands into a web form and attempt to take control of the agent. We do not rely on the model to detect every adversarial input, because the model will miss some. We rely on the environment to treat customer inputs as data, not as commands. The agent can consider what the customer wrote, but the text itself cannot alter the agent's instructions. That separation is a design decision, and it belongs in the runtime, not in the model's judgment.
Teams that put agents into production discover that the hardest work is the unglamorous part. We spend more time removing tools, narrowing scopes, and tightening handoffs than we do composing fluent system prompts. The agents that survive contact with real customers are the ones whose environment is almost boring. They do the job, they look good doing it, and they never surprise the person they are trying to help. Boring is a feature when your company's reputation is on the line.
The Room Is the Company
The reason we are building an agentic hosting environment is that every agent we have put in front of a customer has the same needs. It needs a bounded set of tools. It needs a memory of the conversation that survives across sessions. It needs escalation paths to humans and a governance layer that records what it did so the company can audit it later. Those needs are not specific to demos, onboarding, or investor pitches. They are the requirements of any AI teammate that represents a business in the world.
Seminara is Exhibit A for that thesis. It is the room we built for live product conversations, and it is where we learned how hard it is to make an agent act like a colleague instead of a chatbot. But the infrastructure behind it, the workspace, the state, the enforcement, the handoffs, is the product we actually care about. In a few years, every startup will have ten agents talking to customers, training users, and running internal operations. Those agents will all need a place to stand, and that place will define what they are allowed to promise on the company's behalf.
We are building that place. If you have felt the gap between a promising prototype and a dependable teammate, you are probably not hunting for a better model. You are looking for a working environment where an agent can be accountable, auditable, and effective on a live call. That environment is the infrastructure, and this is the thesis. The agents are the actors, but the room is the company's reputation, and we intend to build a lot of good rooms.
— OmniAI