Agent Core 1.0
Learn how a custom model uses native function calling to choose tools, read results, and complete multi-step tasks.
Agent Core 1.0 is UnieAI Studio's in-process agent loop. For each request, it gives the base model the capabilities currently available to the custom model. The model can choose knowledge-base, database, web-search, API, MCP, or skill tools. Tool results return to the same request history, and the model then decides whether to use another tool or produce the final answer.
Agent Core 1.0 runs inside each Chat Completions request; it is not queued for a background worker to finish later. The API remains compatible with the OpenAI Chat Completions shape. Streaming responses can additionally contain UnieAI reasoning, tool, and metadata events.
Enable Agent Core 1.0
Open the custom model's Customize page and go to Behavior → Agent Loop.
Enable the AI engine and select Agent Core 1.0 (in-house agentic loop), or leave it set to the platform default.
Configure knowledge retrieval, maximum steps, and the default API and MCP tool timeouts.
Bind knowledge bases, databases, API tools, external MCP servers, skills, or memory on their corresponding Behavior pages.
Save and test in the Playground with the intended permissions and data.
Available capabilities
A capability enters the toolset only when the feature is enabled, the resource is bound, and the caller is authorized.
| Capability | When available | Purpose |
|---|---|---|
kb_search | A knowledge base is bound | Search authorized knowledge and return source metadata |
| SQL tools | A usable data connection exists | List tables, inspect columns, and query according to the connection policy |
| Web search | Web search is enabled | Search public web results |
| API tools | API operations are enabled | Call configured HTTP APIs |
mcp__* | An active remote MCP server is configured | Call tools exposed by that MCP server |
load_skill | A skill is bound | Load detailed skill instructions on demand |
memory | Agent Core memory is enabled | Save new durable facts or preferences |
todowrite | Agent Core 1.0 | Maintain a checklist within the current request |
task | Sub-agents are enabled | Delegate a self-contained subtask to an isolated helper agent |
SQL is not inherently read-only. Allowed operations and write access come from the data-connection policy; DDL, multiple statements, and other restricted operations are still rejected. For analysis-only workloads, use a read-only account or Data Hub mirror and enforce access at the data source.
Chart rendering is available only in supported BI-assistant contexts. It does not appear automatically on every SQL-enabled custom model. Sub-agents are also off by default and must be enabled by platform or custom-model configuration.
Conversation context
Agent Core keeps user, assistant, and tool messages in the current request so each model step can read prior results. When history approaches the model's context budget, the runtime attempts to compact older content while retaining recent conversation and useful tool information.
Compaction reduces overflow risk; it does not preserve every old message verbatim. Store information that must remain exact in a knowledge base, data source, or application state instead of relying only on a very long chat history.
Memory and background review
Memory must be enabled separately. Once enabled, the agent can save new durable preferences and facts and retrieve relevant memories on later requests. Each request uses the memory snapshot read at entry; a write made during the turn does not rewrite the system prompt already built for that turn.
After the answer is delivered, a selective background review can:
- Look for durable preferences, corrections, or environment facts
- Look for a reusable method discovered through multi-step tool use
- Update memory or save a skill only when warranted; most ordinary conversations create nothing
Current runtime defaults review memory every 10 user turns and reusable methods after 10 accumulated tool iterations. Deployments can change these values, so they are not an API guarantee.
Sub-agents
When the task tool is enabled, the parent agent can delegate complete, independent subtasks to helper agents. Each helper has its own history and returns only a distilled conclusion to the parent; its intermediate text does not flood the parent context.
The defaults below can be changed by deployment configuration:
- Up to 5 subtasks per parent request
- Up to 8 model steps per helper
- One level only; a helper cannot create another helper
- Helpers do not use the parent's todo list or write long-term memory directly
- Independent tasks requested in one model step can run in parallel
Helper model and tool usage is included in the request's reported token usage.
Reliability and limits
Agent Core 1.0 includes request-scoped safeguards that:
- Retry a limited set of transient upstream 429, 5xx, and connection failures
- Compact long history and retry once after recoverable context overflow
- Bound model steps and individual tool execution time
- Detect repeated calls to the same tool and arguments
- Ask the model to stop using tools and summarize completed and incomplete work near the step limit
These controls reduce runaway loops and abrupt termination, but they cannot guarantee that every external service succeeds or that every failure produces a complete answer. Applications must still handle HTTP errors, empty results, timeouts, and partially completed answers.
Playground timeline
Agent events streamed to the Playground can include:
- Tool start, completion, failure, and output previews
- SQL, web-search, MCP, and other tool metadata
- Upstream retries, context compaction, and repetition warnings
- Sub-agent start and completion
- Guardrail results when guardrails are enabled
Supported events may be persisted or reconstructed from conversation data, but the timeline is not a permanent audit copy of every internal thought, provider response, or stream fragment. Use request, data-source, and external-service logs for formal auditing.
Security and permissions
- Guardrails check input only when configured and enabled; output checking also requires Apply to output.
- The agent sees only the resources and tools resolved for the request, but each external tool receives the arguments needed to execute it.
- Knowledge search returns source metadata, but whether the final answer displays citations depends on the prompt, model, and available results.
- Give write-capable SQL, API, and MCP tools minimum privileges, and enforce validation, idempotency, and auditing at the tool boundary.
- Model and external-service deployment determines where data flows. Agent Core does not replace organizational data-governance policy.