---
title: Run production AI agents without running the infrastructure
description: Pick a template, press deploy, and get a working agent with a model, a URL and a bill you can read. Here is what that actually gets you.
published: 2026-08-15
category: announcements
source: https://buildyourfuture.app/blog/meet-build-your-future
---

Most teams that want an AI agent in production do not want an AI agent project. They want a thing
that answers questions in Slack, or triages tickets, or reads a repository and writes a summary —
and they would like it to still be working next month without anyone owning it.

The distance between those two is larger than it looks. A model provider account. A key nobody
should have. Somewhere to run a container. A queue. A database for conversation state. Logs you can
search at 2am. A way to know what it cost. Roughly a fortnight of setup before the agent does
anything you asked for.

Build Your Future is that fortnight, already done.

<Video
  src="/blog/media/product-tour.mp4"
  poster="/blog/media/product-tour-poster.jpg"
  title="Template to running agent, in about fifteen seconds"
/>

## What you actually get

<Steps>
  <Step title="A running agent, not a repository">
    You pick a template and press deploy. What comes back is a URL with an agent behind it —
    container, volume, health checks, restarts and TLS included. No Dockerfile, no cloud account.
  </Step>
  <Step title="Model access without a key">
    Every request goes through the inference gateway, which holds the provider credentials and
    meters usage per token. You never paste an API key into a config file, and no agent ever sees
    one.
  </Step>
  <Step title="One bill, in cents you can trace">
    Compute and tokens land on the same statement, per agent, per day. Not a seat count, not a
    plan tier you have to translate into what you used.
  </Step>
  <Step title="An upgrade path that is not your problem">
    Templates track their upstream projects. When a new version is released, the agent shows an
    update — you choose when, we handle the build.
  </Step>
</Steps>

## Everything on one screen

The dashboard is the whole surface: which agents exist, whether they are healthy, and what each one
has cost this month. Deploy, pause, redeploy and delete are all one click from here.

<img
  src="/blog/media/product/agents-dark.png"
  alt="The agents list, showing nine deployed agents with status, model, region and spend this period"
  width="3200"
  height="1800"
/>

It follows your system theme, because half of you will read this at night.

<ImageCompare
  before="/blog/media/product/dashboard-light.png"
  after="/blog/media/product/dashboard-dark.png"
  beforeAlt="Light theme"
  afterAlt="Dark theme"
  width={3200}
  height={1800}
/>

## Start from something that already works

Templates are maintained forks of real agent projects, not starter scaffolds. Each one is pinned to
a known-good upstream release, patched where the managed environment needs it, and tested against a
live container before it reaches the catalog.

<img
  src="/blog/media/product/catalog-dark.png"
  alt="The agent catalog, showing Hermes, OpenClaw, Mercury and Scout Research with install counts and pricing"
  width="3200"
  height="1800"
/>

Deploying one takes a name and a model:

<CodeGroup defaultTab="Dashboard">
  <CodeTab label="Dashboard">

```text
Catalog → Hermes → Deploy
  Name    support-bot
  Model   claude-sonnet-5
  Region  auto
```

  </CodeTab>
  <CodeTab label="API">

```bash
curl -X POST https://buildyourfuture.app/api/agents \
  -H "Authorization: Bearer $BYF_KEY" \
  -d '{"template":"hermes","name":"support-bot","model":"claude-sonnet-5"}'
```

  </CodeTab>
</CodeGroup>

## Billing you can argue with

Usage is recorded per request and priced at the token. The usage page shows where the money went,
by agent and by day, and the number on it is the number on the invoice.

<img
  src="/blog/media/product/billing-light.png"
  alt="The billing page, showing the wallet balance and a statement broken into credits and usage"
  width="3200"
  height="1800"
/>

<Callout type="note" title="Why this matters more than it sounds">
  Per-seat pricing for an agent platform is a bet that you will not use it much. Per-token pricing
  means a quiet month is a cheap month, and a busy one is legible rather than a surprise.
</Callout>

## Where your team already is

An agent is not much use if reaching it means opening a dashboard. Turn on Telegram and the platform
creates a bot for that agent, wires the webhook and handles files and rich replies. Everything else
is an HTTP endpoint with a token.

## When one agent is not enough

Novas orchestrate other agents. A Nova holds the roster, decides which agent answers what, keeps
shared memory across conversations, and can run on a schedule — so "summarise yesterday's tickets
every morning at nine" is configuration rather than a cron job you maintain.

- Route a question to the agent that can answer it, or coordinate several that each hold part of it
- Persistent memory across sessions, not a context window that forgets on Monday
- Scheduled runs with a history you can read when one of them misbehaves

<CTA
  title="Deploy your first agent"
  body="Free to start. No card until you spend something, and no key to paste."
  href="/signup"
  label="Get started"
/>

## What it does not do

It is a managed control plane, so the tradeoffs are the ones managed platforms have:

- **You do not choose the cloud.** Agents run on our infrastructure. If your compliance posture
  requires a specific region or account, this is not the right fit.
- **You do not get root.** Agents are containers with a volume and an API, not machines you SSH
  into.
- **Templates set the shape.** You can configure an agent and extend it with skills, but the managed
  path expects something that looks broadly like the templates.

If those are dealbreakers, this is not for you. If they are not, you can have an agent answering
questions before lunch.
