Agent Builder

The Agent Builder is one page: everything an agent needs, then Deploy. Open it from Agents → New agent, which asks how you’d like to start: Start from a template (the Marketplace), Describe it (the Builder with the assistant first and the code folded away under Code), or Write code (the Builder with the editor up front). Agents installed from a template also open with their code folded away when you edit them; the Agents page lists every agent in the workspace. Editing an agent opens the same page and redeploys the same agent - same id, same embed snippets and API calls.

Basics

Name - shown everywhere in backcrew. You can rename it later.
Model - from the models your workspace offers, each with its price per 1,000 tokens. You pay for the model the agent actually calls (see Which models the code can call). Under the picker, the Builder estimates what a typical answer costs on that model, in credits and dollars: 2,000 tokens in and 500 out, plus one knowledge search if you’ve attached knowledge, at least the minimum per request. Hover it to see the assumption. Real answers cost what they actually use, and each test answer on the agent’s page shows its actual cost.
Region - where the agent runs. It’s fixed once the agent exists. Tools and knowledge bases must be in the same region.

Code

A Python project in a multi-file editor:

agent.py (or the file you mark as the entry) defines agent = Agent(...) using the Strands Agents SDK.
Add more files and import them by name.
requirements.txt lists extra packages from PyPI, one per line.

backcrew adds the plumbing around your code - memory, tools, knowledge search, policies and usage metering - so your code stays about what the agent does.

Which models the code can call

Read the model you picked from os.environ["MODEL_ID"]. Your code can also call any other model in backcrew’s model list (the models shown in the Builder); each call is billed at the price of the model it actually used. Calls to models that aren’t in the list are refused. When a model is added to the list, existing agents can call it shortly after, without a redeploy.

How a request runs

Each request runs in its own session, which ends when the agent returns its answer. Anything your code leaves running in the background after the reply is stopped then, so don’t rely on background work continuing after the agent answers.

Code a deploy refuses

Saving or deploying is refused, with the file and line, if the code reaches into the runtime backcrew wraps around your agent:

importing or referring to the __main__ module (the ordinary if __name__ == "__main__": is fine),
touching _make_api_call on the HTTP client library, the model-call hook backcrew uses to meter usage,
referring to backcrew’s internal metering names,
handling the agent’s own credentials: reading them, or signing requests by hand. The libraries your agent uses find its credentials themselves; your code never needs to.

The error starts with “This code changes how backcrew runs and bills your agent, which isn’t allowed: agent.py line 12: …”. Ordinary agent code never needs any of these; remove the line and save again.

Imports that would fail. An agent whose imports fail crashes as it starts, and then can’t answer anything. So saving is also refused, with the file, the line and usually the fix, when the code imports something that doesn’t exist:

a name a standard-library module doesn’t have, e.g. from decimal import decimal → “the decimal module has no decimal (did you mean Decimal?)”,
a name, or a file, that isn’t in your own files, e.g. from probe.tools import add_mony → “probe/tools.py has no add_mony (did you mean add_money?)”.

Imports inside try or if blocks are left alone (they’re allowed to fail), and so are packages from requirements.txt.

Builder assistant

Describe your agent - explain what it should do in plain words, in English or Arabic; the assistant writes the code and suggests tools, knowledge and memory from what your workspace has. You review before deploying. From New agent → Describe it, you first see a plain-language summary (what it will do, what it uses, what it won’t do) and a suggested policy; Create this agent creates the policy if you keep it and deploys the agent through the usual code review. Use it, but let me look first puts the code in the editor instead. Nothing is created until you confirm.
Fix with AI - after a failed deploy, or when a request fails with an error in your code, the assistant reads the error and proposes a fix. You review it before saving.

The assistant is charged on the tokens it uses (see Credits).

What the agent can use

Field	What it does
Tools	Your workspace’s tools this agent may call.
Knowledge	Up to 5 knowledge bases it can search and cite.
Policy	The policy it follows - topics it won’t discuss, actions it never takes.
Quality checks	A set of checks scoring a sample of its answers. Off by default.

Advanced settings

Memory
- Off - every message starts fresh.
- Session - remembers the conversation while it’s open (the same session).
- Persistent - also keeps a long-term record of each person’s conversations.
Code Interpreter - a sandbox where the agent can run Python, for calculations and data work.
Browser - a cloud browser the agent can use to read websites, optionally limited to sites you list.
Hand off to a person - the agent can hand a conversation to your team when someone asks for a human or it can’t help. See Human handoff.

Deploy and status

Status	Meaning
Reviewing	backcrew is reviewing the code before anything is built, usually for under a minute (see Code review).
Review failed	The review stopped this version, and the agent page shows why. Nothing was built; if the agent was already live, it keeps answering with its previous version. Fix the code and save again.
Building	Creating the runtime and everything it uses.
Deployed	Live and answering.
Updating	Saving your changes. The agent keeps answering with its current version until the new one is ready.
Update failed	The changes couldn’t be applied, so the agent is still answering with its previous version. The agent page shows why; fix it and save again.
Failed	The first deploy went wrong, so the agent isn’t answering yet. The agent page shows the error; fix it and save again.
Deleting / Deleted	Being removed / removed, with everything it used.

Saving changes never takes a live agent offline: the dashboard, API, website widget and Telegram keep getting answers throughout.

Code review

Before anything is built, backcrew reviews the code of every deploy and update. It usually takes under a minute, while the agent shows Reviewing, and it’s free (no credits). This comes after the instant check at save described in Code a deploy refuses.

What stops a deploy. Only security problems: code that tries to get around how backcrew runs, meters or isolates agents. For example:

calling a model in a way that avoids backcrew’s normal client,
using or sending the agent’s credentials,
reaching other agents’ or other workspaces’ data,
switching off backcrew’s guardrails or usage metering,
sending conversation data somewhere the agent’s purpose doesn’t explain,
leaving work running after the agent answers.

Packages. Before the review, the packages in requirements.txt are checked against a public database of known-malicious packages. A known-malicious package stops the deploy, and the error names it; remove it and save again. A pinned version (==) is checked as that version.

Watch it happen. While a deploy or update runs, the Builder and the agent’s page list the three checks, Checking code → Checking packages → Security review, and tick each one as it passes. If one stops the version, it’s marked, and the reason shows below as before. Once a version that passed is live, the agent’s page carries a Reviewed · safe to deploy badge with the date of the review; click it to open the review.

A stopped version gets the status Review failed, with the reason. Nothing is built, and a live agent keeps answering with its previous version. Fix the code and save again; that’s an ordinary edit.

Everything else is advice. The review also points out the following, without stopping the deploy:

Bugs - errors, wrong imports, a missing agent = Agent(...), tools without docstrings or type hints, calls without timeouts.
Secrets in code - use a connected tool or an environment variable instead.
A hard-coded model - read os.environ["MODEL_ID"] instead.
Infrastructure names - cloud-provider names in the system prompt or anything end users see.
Rebuilding what backcrew provides - memory, knowledge search, HTTP clients carrying credentials.
Quality - a vague system prompt, unclear tool descriptions.

The results show in the Code review panel on the agent’s page and under the code editor when you edit the agent, and as an entry in the agent’s activity log: a short summary and a list of findings. Each finding has a severity (error, warning or suggestion), the file and line - click it to jump to that line in the editor - what’s wrong and how to fix it.

When the review can’t run. The deploy is also stopped if:

the review couldn’t run - try again later, or contact backcrew support;
the project is too large to review (over about 300,000 characters of code);
the workspace has used its daily number of reviews - try again tomorrow, or contact backcrew support.

Code that’s the same as the last code reviewed for this agent, and passed, isn’t reviewed again.

If you think a stopped version is fine, contact backcrew support. backcrew’s team can review it and approve it, which deploys it. You can’t override a review yourself.

Versions and rollback

Every version of an agent that goes live is kept. Open the agent’s page and choose the Versions tab to see each one, newest first: its number, when it went live, who deployed it, and its code review result (Code review passed, Approved by backcrew’s team, or Not reviewed if reviews were switched off). The version marked Live is the one answering. A version that was stopped by the review or failed to update never becomes a version, so the list only holds versions that actually ran.

Compare with current shows what changed between that version and the live one: the settings that differ (description, model, memory, tools, knowledge, policy, quality checks, Code Interpreter, Browser) and, for each file, the lines removed and added.

Roll back to this version redeploys that version’s code and settings, after you confirm. It works like saving an edit:

It’s the same agent, and it keeps answering with the live version until the earlier one is ready. Nothing goes offline.
The code goes through the code review again, as any update does. If it’s stopped, the status is Review failed and the live version keeps answering.
The agent keeps its current name. If the earlier version used a tool, knowledge base, policy or quality check that has since been deleted, the rollback is refused; edit the agent instead.
Once it’s live, the rollback is listed as a new version (“rollback to version 1”), so you can always go forward again.

Rolling back needs the Owner or Builder role, and each one is recorded in the audit log with the version number. Deleting an agent deletes its versions too.

Starting from the Marketplace

A Marketplace template becomes an ordinary agent in your workspace: you can edit it like any other, and its requests use credits like any other.

Some templates work with tools, such as a document store or a ticketing system. A template can’t bring connections or credentials, so when you click Install you choose your own tools for it:

Each tool the template expects is listed with its category, marked Required or Optional. Only your active tools of that category in the region you’re installing to are offered.
No suitable tool yet? Click Create one to add it without leaving the dialog.
Install is available once every required tool is chosen. The agent is then deployed once, with your tools attached.

If you skip an optional tool, the agent opens on its edit page with that tool’s slot at the top, and its page shows Not finished until you attach it.

Arabic templates. Two templates are written in formal Arabic, with English when the user writes in English:

Arabic Customer Service (خدمة العملاء بالعربية) answers your customers, looks up an order through the order system you attach (optional; without it the agent says it can’t check orders), and writes a hand-off summary for your team when it can’t resolve a request.
HR Policy Q&A (أسئلة سياسات الموارد البشرية) answers employees from your own HR documents and names the document it used. After installing, attach your HR policies as knowledge on the agent’s edit page; until then it says it can’t find an answer.

Both work well with the Arabic policy presets on the Policies page. In the test console and the website widget, Arabic answers read right to left.

Setting up the Cloud Operations template, step by step: Cloud Operations agent.