From the app to production

Say you want a support chatbot on your website. It should answer from your documentation, sound like your company, and admit when it does not know.

Done conventionally, that is a project: retrieval, a vector store, prompt engineering, an evaluation harness, guardrails, a deploy pipeline, and a long series of meetings in which somebody who understands support tries to explain to somebody who understands Python what a good answer looks like.

Here it is two jobs that barely touch.

What the domain owner does, in the app, without code

Put the source material in a collection. The help centre, the FAQ, the policy pages. Upload them or point at a Drive folder that already has them, and let it stay in sync.

Build the agent. Instructions in plain language: who it serves, what to do when unsure, what never to promise. Pin the collection so it always searches it.

Use it, and correct it. This is the part that cannot be delegated and is usually skipped. Ask it the questions you actually get. When it is wrong, fix the instructions, not the message.

Write down what "right" means. Twenty cases in an evaluation dataset: the ordinary questions, the ones it should decline, and one with a false premise. Now "is it good?" has an answer that survives the next change.

Share it so it is callable beyond their own account.

None of that needs an engineer, and all of it needs the person who knows the domain.

What the developer does

Get a project API key, and call the agent by its slug.

const res = await fetch("https://api.asteria-labs.com/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.ASTERIA_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    agent: "support-bot-h26dx",
    messages: history,
    stream: true,
  }),
});

That is the integration. It is the OpenAI request shape, so an existing chat UI or SDK works by changing two constants.

What the developer does not build: retrieval, chunking, embeddings, a vector database, prompt assembly, an eval harness, per-tenant document isolation, or a way for the support team to change the wording without a release.

Why this is faster, specifically

Not because anyone writes less code. Because the loop that usually dominates the schedule disappears.

The expensive part of a project like this is rarely the software. It is that the person who can judge the answers cannot change them, and the person who can change them cannot judge them. Every correction becomes a ticket, a sprint, a deploy, and a re-test by the only person qualified to tell whether it worked.

Here that loop is one person in a browser, and it closes in minutes. The engineering work stops being "build a RAG system" and becomes "call an endpoint", which is a Tuesday.

After launch, the split holds

Support owns the answers. The agent's instructions and collection change in the app, and the change is live immediately. No deploy, no ticket, no engineer.

Engineering owns the surface. The endpoint contract does not move when the agent's instructions do.

What you still own

Being straight about the boundary:

• The interface. We return messages, you render them.
• Who is asking. Your key is your application's, so end-user identity, sessions and rate limits per user are yours.
• What you send. Conversation history is passed on each request, so you decide what a session is and how much of it to carry.
• The last mile of trust. If an answer must never contain X, test for X. The agent's instructions are a strong lever, not a guarantee.

Where to look next

• Projects to separate the staging key from the production one and watch the spend.
• Getting started for the first call.
• Cookbooks for worked recipes.
• The user guide's Agents and Evaluations sections, which are what you hand to the colleague doing the first half.