Build an agent project

An agent project is a Tensic project that can act, not only answer. It has one LLM, a system prompt, tools it can call, memory, and secrets. Use an agent when the model has to fetch data, run code, call your systems, or remember earlier conversations. For stateless request/response calls, an inference project is enough.

How an agent project differs from other project types

An agent project is built around state and actions:

• One LLM. An agent uses exactly one model. There is no default/fallback model list and no automatic failover, because the agent's memory and running state are tied to how that model behaves. Choose the model deliberately.
• Tools. The agent can call built-in tools (terminal, crawler, calculator, web search and more), tools it creates itself, external MCP servers, and skills.
• Memory. Within a session the agent remembers the conversation. Cross-session memory (memory bank and memory search) is optional; see Give an agent memory.
• Secrets. Credentials are stored encrypted and injected into the agent's sandbox, never into the prompt.
• Shared project features. Budgets, logging, routines, access control and integrations work the same way as in other project types and use the same screens.

The project page has these tabs: Overview, Configuration, Prompt, Tools & MCP, Memory, Secrets, Integrations, Orchestration, Routines, Access, Guards and more. Use Playground at the top to chat with the agent and Logs to review each request.

An agent without tools does not pretend. Ask it to fetch a web page and it explains that it has no browsing tool. Add the right tool and the same request works.

Give the agent's team an embedding model

A project can only use the models its team has been allocated, and it spends from the team's budget. If the embedding model list on the agent's Configuration tab is empty, the team has no embedding model yet. Embeddings are required for memory bank, memory search and knowledge search.

1. Open the team that owns the agent project.
2. Open the Models tab of the team.
3. Under Team Embedding Models, open Select Embeddings and pick an embedding model. (Alternatively, turn on Use every model in this instance to grant the team every model, including models added later.)
4. Click Save.
5. Return to the agent project, open Configuration, and select the model under Embeddings next to the LLM field. Save.

Write the agent's system prompt with presets, AI generation and variables

The system prompt defines the agent's role, tone and constraints and is prepended to every conversation.

1. Open the Prompt tab.
2. Write the prompt in the Prompt box, or start from one of the Presets (for example General assistant, Code assistant, Extract data (JSON), Input guard, Output guard).
3. To draft a prompt with a model, click Generate with AI and describe what the agent should do. Review the result before saving.
4. To personalise the prompt per request, reference variables in the form {{context.name}}. Every variable used in the prompt is listed under Variables; saving the prompt declares any you have not added yourself. Use Add variable to declare one explicitly and give it a default.
5. Click Save.

A variable without a default is required: a request that omits it is refused rather than silently sent with a blank value. Every save is recorded under Prompt history (newest first), so you can see earlier versions.

Mention the tools you want the agent to prefer in the prompt, and scope the agent's objective as narrowly as you can. Focused objectives give faster, more reliable results than open-ended ones.

Add built-in tools such as the terminal and crawler

Tools are what let an agent do work. Add them on the Tools & MCP tab.

1. Open Tools & MCP.
2. In Behaviour, open Built-in tools and select the tools the agent may call. Available tools include calculator, connect_ssh, crawler_classic, crawler_selenium, create_routine, create_tool, data_parser, datetime_tool, draw_image, duckduckgo, terminal and more.
3. Click Save. The Active tools graph at the top of the tab shows the agent and every tool bound to it.
4. Test in Playground, for example: "Get me the news from ".

Useful tools to know:

• terminal gives the agent a computer. It can write and run code, use command-line tools, download and unpack files, and analyse them. With the terminal alone the agent can do almost anything, but it takes more steps and tokens.
• crawler_classic fetches and reads a web page in a single tool call. Fetching the same page through the terminal takes several calls (download, then parse the HTML) and is slower.
• Search knowledge connects the agent to a RAG project; see Build a RAG knowledge base.
• search_memories searches the agent's own past conversations; see Give an agent memory.

Give the agent a purpose-built tool when one exists. It is faster and cheaper than letting the agent work it out in the terminal.

What the agent sandbox is

Everything the agent runs through the terminal tool is executed in a sandbox: an isolated container.

• A sandbox belongs to a session (a conversation), not to a single message. Files and state created earlier in the conversation are still there for later messages.
• Starting a new session creates a new, clean sandbox.
• Sandboxes are isolated from each other, so one session cannot see files from another.

This is the same model used by coding agents such as Claude Code. Because each session has its own sandbox, a session that installs tools or writes files does not affect other users of the agent.

Choose the agent loop and agent mode

The agent loop (also called the agent harness) is the runtime that drives the cycle of thinking, calling tools and reading results. Set it on Tools & MCP > Behaviour.

• Agent loop: the default, tensic.ai (default — any LLM), is tuned for smaller open models such as GLM and Qwen: it keeps long sessions on track and avoids loops and repetition. Other harnesses are available, including Anthropic's Claude SDK, the OpenAI SDK, LlamaIndex and smolagents. Those are optimised for large frontier models; the OpenAI SDK loop is meant for OpenAI models. Keep the default unless you have a specific reason.
• Agent mode decides how tools are called:
  • Auto (native, fall back to ReAct) (default): uses the model's native function calling when it supports it, and automatically falls back to text-based ReAct prompting when it does not. This keeps tool calling reliable on smaller models.
  • Function calling (native only).
  • ReAct (text-based prompting).
• Auto-plan multi-step tasks: runs a one-shot planner call before the first turn.

Set iteration and time limits for agent requests

Every agent request runs under limits so that a looping agent cannot run forever and burn tokens, compute and budget. Set them on Tools & MCP > Behaviour:

• Max iterations: tool-calling iterations per request (default 10).
• Tool timeout (s): maximum time per tool call. Empty uses the instance default (120 s).
• Run timeout (s): maximum time for the whole request, all steps included. Empty uses the instance default (300 s).

When a request reaches a limit, the agent stops and returns what it has so far, with a message that the request hit its limit and that partial results are shown. If that happens:

1. Narrow the request, or use a faster model.
2. For legitimately long tasks (for example analysing a large file), raise Max iterations and the timeouts, for example to 100 iterations and 300 seconds.
3. Click Save and run the request again.

Raise limits step by step rather than removing them; the defaults are there to protect your budget.

Store credentials as agent secrets

Use secrets for API keys, tokens and passwords that tools need.

1. Open the Secrets tab.
2. Click Add secret and add the credential.

Secrets are stored encrypted in the project's vault. They are injected into the agent's sandbox as environment variables and never enter the agent's context, so the model cannot repeat them in an answer. To use a secret in a tool the agent created, select it in that tool's Project secrets settings; see Extend an agent with tools, MCP servers and skills.

Common questions