mech.app

The mech.app newsletter

Agentic AI, minus the noise.

Get practical field notes on AI agents, automation, developer tools and security delivered to your inbox.

No spam. Unsubscribe anytime.

AI Agents

Backprompter's Zero-Backend Agent Deployment: How Client-Side Orchestration Eliminates Infrastructure Setup

Architectural trade-offs of deploying production agents without backend infrastructure: authentication delegation, state management, and failure modes.

Source: backprompter.com
Backprompter's Zero-Backend Agent Deployment: How Client-Side Orchestration Eliminates Infrastructure Setup

Backprompter removes the backend from agent deployment. You write a system prompt, test it with mock users, and click deploy. The result is a hosted chat UI or an SDK call that runs your agent without standing up servers, managing secrets, or configuring databases.

This is not a framework. It is a hosted service that handles authentication, state persistence, and API orchestration so you can ship agents without writing infrastructure code. The trade-off is control. You delegate secret management, user auth, and execution context to Backprompter’s runtime. In return, you skip weeks of plumbing.

How It Works

Backprompter provides three deployment paths, each with different boundaries between your code and its runtime:

Hosted chat UI: Backprompter serves a complete frontend at your-app.web.app/chat. You configure sign-in methods (anonymous, Google, email) and share the URL. No frontend code required.

Client-side SDK: You build the UI. Backprompter handles auth and agent execution. Your frontend calls Backprompter.run() with an agent ID and user prompt. The SDK manages session tokens and routes requests to Backprompter’s execution layer.

Backprompter.setAppKey('your-app-key');
await Backprompter.signInAnonymously();

const { response } = await Backprompter.run({
  agentId: 'support-bot',
  userPrompt: message,
});

Server-side SDK: You own user auth. Backprompter becomes a stateless agent executor. Your backend passes an API key and tenant ID with each request. Backprompter never sees your users’ credentials.

const bp = new BackprompterServer({
  apiKey: process.env.BACKPROMPTER_API_KEY,
  tenantId: process.env.BACKPROMPTER_APP_KEY,
});

const { response } = await bp.run({
  agentId: 'support-bot',
  userPrompt: ticket,
});

The hosted and client-side paths delegate authentication to Backprompter. The server-side path treats Backprompter as a function call: you send a prompt, you get a response, and you manage everything else.

Authentication and Secret Management

When you use the hosted UI or client SDK, Backprompter manages user sessions. It issues JWT tokens, stores them in browser storage, and validates them on each agent call. Your agent configuration includes API keys for external services (OpenAI, Anthropic, HTTP endpoints). Backprompter stores these secrets server-side and injects them at runtime.

This creates a trust boundary. Your API keys live in Backprompter’s secret store, not your infrastructure. If you need to call a private API that requires per-user credentials, you have two options:

  1. Pass user-specific tokens as parameters in the SDK call. Backprompter forwards them to your agent’s tool definitions.
  2. Use the server-side SDK and handle auth yourself. Backprompter never sees user credentials.

For hobbyists and small teams, delegating secret management is a win. For enterprises with compliance requirements, the server-side path keeps credentials in your control.

State Persistence and Version Control

Backprompter stores conversation history per user and per agent. When a user sends a message, the SDK retrieves the last N turns from Backprompter’s database and includes them in the LLM context window. You configure the context length in the agent settings.

Version control is snapshot-based. Each time you edit an agent’s system prompt, tools, or model selection, Backprompter creates a new version. You can test the new version in the workspace, compare it to previous versions using mock conversations, and deploy it with one click. The deployment updates the production agent ID to point to the new version.

This is not Git. You cannot branch, merge, or diff prompt changes line-by-line. The version history is a linear list of snapshots. For teams that need collaborative prompt engineering with code review, this is a limitation. For solo developers and small teams, it removes the friction of managing prompt files in a repo.

Natural Language Orchestration

Backprompter supports “combo-agents” that route messages to multiple sub-agents. You define orchestration by tagging agents and describing the routing logic in natural language. For example: “Route technical questions to the support agent and billing questions to the payments agent.”

Under the hood, Backprompter uses an LLM to parse your orchestration description and generate a routing function. This function runs on each incoming message and selects the appropriate agent. The routing decision is not deterministic. If your orchestration description is ambiguous, the router may pick the wrong agent.

This is the core trade-off of natural language orchestration. You skip writing explicit routing logic, but you lose guarantees about which agent handles which message. For simple workflows (support vs. sales), this works. For complex state machines with strict routing rules, you need a different tool.

Tool Calls and RAG

Backprompter supports HTTP API tool calls and retrieval-augmented generation (RAG). You define tools by specifying an endpoint, HTTP method, headers, and request body template. The agent decides when to call the tool based on the system prompt and user message.

RAG works by uploading files to Backprompter’s storage. The service chunks the files, generates embeddings, and stores them in a vector database. When a user sends a message, Backprompter retrieves relevant chunks and injects them into the LLM context.

Both features run server-side. The client SDK sends a message, Backprompter executes tool calls and RAG retrieval, and returns the final response. This keeps API keys and embeddings out of the browser, but it also means you cannot inspect or debug tool calls in real time. Observability is limited to conversation logs in the Backprompter workspace.

Deployment Trade-Offs

Deployment PathAuth OwnershipSecret ManagementState PersistenceUse Case
Hosted UIBackprompterBackprompterBackprompterFastest path to production, no code
Client SDKBackprompterBackprompterBackprompterCustom UI, delegated backend
Server SDKYouBackprompter (API keys only)YouFull control over user data
Self-HostedYouYouYouNetwork-internal apps, compliance

The hosted UI and client SDK are optimized for speed. You trade control for convenience. The server SDK and self-hosted version give you control but require more setup.

Failure Modes

Token limits: Backprompter does not enforce hard limits on context length. If your conversation history plus RAG chunks exceed the model’s token limit, the request fails. You must manually configure the context window size in the agent settings.

Tool call latency: HTTP tool calls run synchronously. If a tool takes 30 seconds to respond, the user waits 30 seconds. Backprompter does not support async tool execution or streaming partial responses during tool calls.

Secret rotation: If you rotate an API key in your external service, you must update it in Backprompter’s secret store. There is no automated secret rotation or expiration warning.

Version rollback: You can deploy any previous version, but you cannot roll back automatically if a new version fails. You must manually select the old version and redeploy.

Client-side secret exposure: If you pass user-specific tokens as SDK parameters, they are visible in browser dev tools. Use the server SDK for sensitive credentials.

Observability

Backprompter provides conversation logs, evaluation scores, and version history in the workspace. You can simulate conversations with mock users and score responses manually. There is no integration with external observability tools (Datadog, Sentry, Langfuse).

For production debugging, you rely on conversation logs. If an agent produces a bad response, you review the log, identify the failure (bad prompt, missing context, tool error), edit the agent, and redeploy. There is no distributed tracing, no latency breakdown, and no error rate dashboard.

This is sufficient for hobbyists and small teams. For production systems with SLAs, you need to export logs to an external monitoring system or use the server SDK and build observability yourself.

When to Use Backprompter

Use Backprompter when:

  • You want to ship an agent in hours, not weeks.
  • You are a solo developer or small team without dedicated DevOps.
  • You trust a third party to manage secrets and user data.
  • Your agent workflows are simple (single-turn or short conversations, HTTP tools, basic RAG).
  • You do not need real-time observability or distributed tracing.

Avoid Backprompter when:

  • You need strict control over user credentials and data residency.
  • Your orchestration logic requires deterministic routing or complex state machines.
  • You need to debug tool calls and LLM decisions in real time.
  • You require automated secret rotation, rollback policies, or SLA guarantees.
  • You need to integrate with existing observability or incident response tools.

Technical Verdict

Backprompter removes the infrastructure tax from agent deployment. For hobbyists, academic projects, and MVPs, this is a clear win. You skip backend setup, secret management, and database configuration. The cost is control: you delegate auth, state, and execution to a hosted service.

The natural language orchestration is a gamble. It works for simple routing but fails when you need predictable behavior. The lack of observability tooling means you cannot debug production issues without manual log review.

If you are building a side project or proof-of-concept, Backprompter is the fastest path to a working agent. If you are building a production system with compliance requirements or complex workflows, use the server SDK or self-host. The hosted UI and client SDK are optimized for speed, not control.