UGENT

Appearance

UGENT Feature List ​

A complete catalog of what UGENT can do, organized by category. Each feature links to its configuration guide or user manual where available.

Multi-Model LLM Routing ​

Route conversations to the right model automatically — or let users pick.

  • Multi-provider support — OpenAI (GPT-6 Sol, Luna and Astra, GPT-6.1 Sol), Anthropic (Claude Opus 5.5, Sonnet 5.5, Haiku 5.5), Google Gemini, DeepSeek, DashScope, Moonshot, GLM, MiniMax, OpenRouter, and any OpenAI-compatible endpoint or gateway. Configure each as a named instance and switch instantly. See LLM Providers.
  • One model catalog — Limits, prices and refused parameters for every catalogued model, built in or from UGENT_MODELS_FILE, never from the folder UGENT starts in. Gateway ids such as us.openai.gpt-6-sol find their entry by themselves. See Model Catalog.
  • Cost estimates — Costs come from public list prices and are labelled as estimates in the TUI and the web workspace.
  • Per-turn models — A turn runs on the model it names (/with, a cron task's target, a chat request's model). That model is never stored as a preference, and a delegating turn finishes on it. See Which Model a Turn Runs On.
  • Per-user model selection — Users pick their own model from an allowlist you define. A model named on a request runs that turn alone; only /model stores a user's choice, which never affects anyone else. See Per-User Model Selection.
  • LLM instance failover — If one provider goes down, UGENT automatically tries the next configured fallback instance — no dropped conversations.
  • Cross-provider reasoning — Thinking and reasoning-effort parameters work across OpenAI, Anthropic, Google and OpenAI-compatible providers. UGENT translates the parameters so each provider gets the right format, and replays reasoning only to the provider and endpoint that produced it.
  • Per-model request rules — UGENT leaves out temperature where a model refuses it, chooses Chat Completions or the Responses API per model, and sends each model the reasoning settings it accepts.
  • Prompt cache requests — Sends cache-control headers to providers that support them (Anthropic, OpenAI), reducing latency and cost on repeated context.
  • Unified multimodal input — Images, audio, and documents are normalized into a single input format that works across all providers. No per-provider image handling code needed. Audio reaches a model only on a route that carries it; others get the transcript.
  • Media generation — Generate images (Agnes, OpenAI, Google Nano Banana), video (Seedance 2.5 up to 30 s at 1080p, Google Veo, Agnes), and audio (Seed Audio 1.0 with voice cloning and music). Delegated to specialized media providers via provider_target.

Decision Models ​

Typed yes/no, choice and score questions answered with calibrated probabilities in one pass — at a fraction of a chat model's price.

  • Both wire dialects, one config — The TypeSafe-style systemone dialect (TypeSafe Jev, SubQ Snap, OpenRouter's mirror, LM Studio, llama.cpp, startlux-decide, Ollama, vLLM) and OpenAI's decisions dialect (gpt-6-luna) from one [decisions.instances] section with provider presets. See Decision Models.
  • The decide tool — Batched typed questions with per-answer probabilities, confidence, and none_probability where a backend reports it; usage and cost on every call. Registered only when an instance resolves.
  • Decision routing — decision_classify and decision_guard routing detectors classify or screen the inbound message before the chat model is paid for, including a prompt-injection guard that blocks with a reason. See Routing.
  • Answer verification and tool gating — Opt-in [decisions.verify] scores is-this-wrong flags over a finished answer (annotate-only, pairs with instance failover), and [decisions.gate] declines risky tool calls with a reason — restriction-only, it never lowers any other check.
  • Secrets and cost tracking — Vault-backed keys with redaction and audit, broker egress profiles for TypeSafe and SubQ, and per-call cost estimates recorded into telemetry.

Voice ​

Let people talk to the agent and hear it answer.

  • Voice messages and dictation — A recording sent from the web workspace is transcribed before routing, so rules, the model and the conversation read the same words, and a model that hears audio also gets the recording. Under an enforced classification scheme a recording reaches only instances cleared for it. Dictation turns speech into editable text without running a turn. See Voice.
  • Answers read aloud — A finished answer is spoken a few sentences at a time by Gemini, OpenAI or an OpenAI-compatible speech server, with code and links described rather than read out; the answer to a voice message can play by itself.
  • Live calls — A spoken conversation over OpenAI's Realtime API whose voice model hands work to the agent as ordinary turns of the conversation. The provider key stays with the daemon, and the call is kept in the conversation afterwards.
  • Realtime sessions in the TUI — /live holds a realtime session with OpenAI or Azure OpenAI, on the same Realtime code a web call uses, or with Gemini Live (so far checked against recorded protocol frames only), with full-duplex audio in builds with the live-audio feature. See Slash Commands.

Context Intelligence ​

Ground every answer in your actual codebase, documents, and data.

  • Pre-LLM code context — Before the LLM responds, UGENT retrieves relevant code snippets from the context engine and injects them into the prompt. The LLM sees your code without you pasting it.
  • Knowledge graph — Builds a graph of code relationships (calls, imports, contains, references) during indexing. Ask "what depends on this function?" and get a structured answer. See Context page.
  • Hybrid search — Combines semantic vector search with lexical BM25 keyword matching, fused by Reciprocal Rank Fusion. The best of both worlds for recall and precision.
  • Cross-encoder reranking — Optional second-pass reranking improves relevance by 40–60% on top results. Supports self-hosted and cloud rerankers.
  • AST-aware chunking — Code is split on function, class, and struct boundaries — not arbitrary character windows. Supports 20+ languages including Rust, Python, TypeScript, Go, Java, Apex, and more.
  • Document versions — The context engine keeps every version of a policy, contract or law, and search shows the one its type says is in force: the file as it stands now, the newest approved policy, or the law in force today, switching by itself when a dated text takes effect. Agents read any version you may open, cite exact passages that stay valid after the document changes, and compare two versions deterministically, with changed numbers and negations flagged. See Document Versions.
  • Database understanding — Index PostgreSQL and MySQL databases. Ask data questions in plain English and get safe, auto-generated SQL grounded on auto-profiled table statistics. See Context page.
  • Salesforce intelligence — Index Salesforce DX projects (objects, fields, flows, permissions, layouts, Agentforce bots) and sync Salesforce record data into one unified knowledge graph. See Salesforce page.
  • External data connections — Tenants authorize their own SaaS accounts (HubSpot CRM today) through OAuth with PKCE and the engine indexes the records into their workspace. Read-only, tenant self-service, with per-connection access rules.
  • Standalone context daemon — ugent context-daemon runs only the context ingestion client — no LLM, no tools, no agent. Monitors multiple workspaces at once with per-workspace codebase IDs, tokens, and sync state.

Security ​

Keep secrets safe, block prompt injection, and enforce boundaries.

  • Injection Firewall — Source-boundary taint tracking prevents untrusted content (web pages, tool output, uploaded files) from issuing commands or exfiltrating secrets through the LLM. Strict mode blocks suspicious tool calls before they execute. See Security & Firewall.
  • Secret Vault — Store API keys and tokens in an encrypted local vault and reference them from config as @secret_ref handles. Two backends: OS keychain (macOS Keychain, Windows Credential Manager, Linux Secret Service) or an encrypted file vault with a passphrase. Secrets are only accepted via stdin pipe (clipboard piping with pbpaste / xclip) — never on the command line, never in shell history. Use ugent secret init/add/list/inspect/rotate/delete/audit to manage them, ugent secret rekey to change the file-vault passphrase, and ugent secret credentials check to validate systemd credential grants. See Vault & Secrets.
  • Secret Broker — An optional local daemon that acts as a credential-injecting egress gateway. Two deployment modes: Native mode (each instance resolves keys from its own vault) or Shared broker mode (one machine-wide daemon holds all credentials, and every instance connects to it — the decrypted key lives in exactly one process). Supports 11 built-in LLM providers (OpenAI, Anthropic, Google, DeepSeek, DashScope, Moonshot, GLM, MiniMax, OpenRouter, Jina, Voyage) plus custom providers. Run as a Linux systemd service for production. Third-party apps can point their SDK at the broker gateway and use the bootstrap token as the API key — the broker swaps in the real credential. See Vault & Secrets.
  • OS sandbox for spawned processes — Kernel-enforced containment for everything UGENT runs: sandbox-exec (Seatbelt) on macOS, bubblewrap on Linux. Five spawn classes (bash, tooling, MCP servers, external agents, plugins) each get their own write-allowlist policy, credential directories are read-denied at the OS level where a shell command cannot walk past it, a startup probe asserts enforcement rather than presence, and workspace configs can only tighten the sandbox, never loosen it. Three modes: off, auto (default), and required (refuse to start unconfined). See OS Sandbox.
  • Data classification — An ordered, customer-defined scheme of sensitivity levels alongside the disjunctive access labels: a document must pass both, so a clearance admits its own level and every level below it and nothing above. Levels, their order, their display names in any language, the path rules and the in-document markers are all configuration — nothing in code names a level. A marker in a document's own text can only raise its level, so a confidential file saved in a public folder is still caught. Documents carrying no level are hidden from a classified caller rather than shown, so enabling a scheme fails closed until the corpus is re-stamped. Database tables take the level of their db:// path, and it binds live SQL as well as search: a caller cannot query a table above their ceiling, and the model writing their SQL is never shown it. A re-stamp re-reads text markers from each document's stored text, so changing one needs no re-ingest and no re-embedding. See Data Classification.
  • Model egress ceilings — Where a document's text may be sent, as distinct from who may read it. The engine's own four model calls — embedder, semantic extraction, reranker, synthesis — each get the highest level they are approved to receive, enforced server-side with no client involved. Withholding is chosen to lose least: a document above the embedding ceiling is still indexed for keyword search and simply has no vectors. The model that answers a turn is capped separately by the caller's declared max_classification, which can only narrow what the asking actor may already read; a deployment can refuse any request that declares none.
  • Conversation ownership on channels — On the web channel a conversation belongs to whoever first sends a message, uploads a file or starts a call in it. Each API key has a role: an operator key is a trusted front end that may name any user and act on any conversation, and an application key may name only federated users of the issuers it lists. Turns, question replies, events, files, live calls, stop and session snapshots are checked against the owner, so an application key, or knowing a session id, is not enough to act on someone else's conversation. See Security & Firewall.
  • Grants and leases — Access is deny-by-default. Configure per-secret grants that authorize specific consumers, purposes, allowed hosts, and TTLs. Every issue and denial is audited.
  • Environment projection — ugent secret exec --env VAR=@secret_ref -- <command> checks every target, resolves every value, then, on Unix, replaces itself with the program, which runs with its secrets and never with the vault passphrase. Works for any language, any tool, zero code changes.
  • systemd credentials — The shared broker answers systemd LoadCredential= requests and a root-owned /etc/ugent/credentials.toml grants each unit its secrets, so a service gets exactly what it is granted, without the passphrase. ugent secret credentials check validates the grants and prints each unit's drop-in. See Vault & Secrets.
  • Vault passphrase stays with its holders — No process UGENT starts inherits the file-vault passphrase: not the model's shell, MCP or LSP servers, skills or plugins. Only the broker UGENT starts for itself is given it. On Linux holders are non-dumpable, and ugent secret rekey re-encrypts the vault under a new passphrase. See Vault & Secrets.
  • Per-person folders — In a workspace with a folder per department or per person, each person's turns, Files and record cards reach only their own folder, their department's shared folder, the workspace's shared folders and what their row adds; administrators pick people by name in Runtime → File confinement. See File Confinement.
  • Delegated work acts for its user — Delegated workers, resumed parents and remote swarm tasks act for the user whose turn delegated them, never the workspace owner, and one user's tasks are invisible to another's turns. See Security & Firewall.
  • Workspace trust — Each workspace is explicitly trusted before UGENT loads its config. Untrusted workspaces require onboarding consent, preventing accidental execution of malicious project-level config.
  • Approval-before-action — Every write operation (file edits, shell commands, API calls) can require explicit human approval before execution. Read-only operations auto-approve.
  • Unattended shell mode — For CI and automation, --allow-unattended-bash permits bash and Python execution after validator checks without authorizing native writes, session changes, or cron mutation.

Orchestration ​

Coordinate multiple agents, tools, and external systems.

  • Sub-agent delegation — A manager agent can dispatch specialist sub-agents (researcher, coder, tester, reviewer) with scoped tools and independent LLM instances. Results merge back automatically.
  • Swarm P2P — Trusted UGENT instances on different machines delegate tasks to each other over an encrypted peer-to-peer channel, with no central server. A remote task acts for the delegating user, never the receiving node's owner; only the submitting peer can read or cancel it; trust changes apply within seconds; a node serves nothing until its config enables swarm. See Security & Firewall.
  • External agent monitor — Orchestrate Claude Code and OpenAI Codex sessions from inside UGENT. Use /claude or /codex to dispatch with full control over permission modes, iteration limits, and auto-resume policies.
  • Parallel tool execution — Multiple tools run concurrently by default (8 parallel calls). Read-only tools batch together; write tools serialize to prevent conflicts.
  • Background shell jobs — Long-running shell commands run in the background with push notification on completion. If a job times out, UGENT auto-adopts it so the result is never lost.
  • In-flight turn steering — Send additional instructions while the LLM is mid-turn. UGENT injects them before the next iteration without interrupting active tool calls.
  • Turn cancellation — Cancel an in-flight turn with /recall in the TUI, or Stop in the web UI. Pending tool calls and delegated work are cleanly stopped; the web UI says whether the agent confirmed the stop, and /recall also removes the turn from history.
  • Retained sub-agents — A finished sub-agent keeps the context it built. Ask it more with a follow-up rather than briefing a fresh worker and paying to rebuild what it already knows. Workers age out from the last time they were addressed, not from when they finished, so one under active follow-up stays alive.
  • Task list — /task status, /task stop, /task continue and /task force-complete work on the session's task list, the plan the agent keeps for its work.
  • Ordered delegation — A delegated task starts only once its dependencies have finished as it needs. A failure fails the whole chain that needs it, and a waiting parent is resumed and told how each task ended. After a restart, nothing that may have acted runs again: interrupted work is reported, and the agent asks before redoing it. See Tasks and Checks.
  • Structured handoffs — A parent receives every child's outcome, summary, evidence and open items, failed and missing children included, and can read a child's whole report on demand.
  • Restrictions follow delegated work — A task carries the opt-outs and tool limits of the turn that created it, and a restricted task never leaves the node. See Service Callers.
  • Checked coding tasks — Off by default. With [task_acceptance], a delegated coding task completes only when your test command, run in an isolated copy of the workspace, shows enough tests ran and none failed. The web workspace then shows Verified snapshot for exactly the version checked. See Tasks and Checks.

Grounded Document Work ​

Draft, triage and answer with a person in the loop and evidence on the record.

  • Section-by-section drafting — document_draft builds a document from a template you define, gathering evidence per section as the calling user so the engine filters to what they may read. Citations are checked against what was gathered for that section: an invented one, or one carried over from another section, is removed and reported. A section with no verified evidence renders behind a configurable needs-confirmation label rather than being written as fact. See Drafting & Expert Answers.
  • Confirmation that survives a rewrite — A reviewer confirms a section and it is never re-gathered or rewritten; only the person who confirmed it can withdraw that, by either route that clears it. The withdrawal records who confirmed, who withdrew and how, so a rewritten section does not silently lose the fact that different content was once approved.
  • Rubric-based intake screening — requirement_screen scores each criterion in its own call against a rubric you write, with score anchors that keep runs comparable. Every score carries a verbatim quote checked against the requirement text — a quote that is not there discards the score — and the weighted total is computed in code, never by the model. Requirements are flagged for a person when too little was assessable or a duplicate was suggested. See Drafting & Expert Answers.
  • Duplicate suggestion, never merge — Embedding cosine where a model is configured, character-bigram overlap otherwise (which works on Chinese, where word overlap does not). Two requirements can be near-identical and differ in the one detail that matters, so a person decides. A rubric chooses whether it dedups against the submitter's own history or one shared team ledger.
  • Expert routing and write-back — expert_desk routes a question to whoever owns the topic from a roster you configure, notifies them on their channel where a frontend is listening, and records the answer as knowledge for the next person. Escalation triggers are things the tool can check — too few verified citations, a section still needing confirmation — never the model's own confidence. Under actor confinement only an expert the question was routed to may answer it, because the answer is published under their name. See Drafting & Expert Answers.

Continual Harness ​

Let the agent learn from a session, but keep a person in the loop. See Continual Harness.

  • Propose-only refinement — /refine reads a finished session and proposes small, evidence-backed edits to a durable set of operating lessons. Nothing reaches a model until you approve it with /harness approve.
  • Reviewable queue — List, inspect, approve, reject, or roll back proposals. /harness show prints the exact text that would be injected, and rollback reverses a whole refinement pass.
  • Oversight scope check — Proposals that would reduce oversight or widen what runs unsupervised are refused outright, never queued. A harness entry is injected into future sessions — a shared one into every session, a personal one into each of its owner's — so an edit of that shape is a persistent change to supervision rather than one bad turn.
  • Bounded queue — A cap on pending proposals bounds both whether a pass runs and how many it may add, so the review queue stays something a person can actually read.
  • Personal lessons on channels — Off by default. With allow_channel_review, each channel user refines their own sessions and decides only their own proposals, and what they approve reaches only their own sessions. The shared set stays with the operator and anyone listed in global_review_actors.
  • Lessons are guidance — Approved lessons reach the model as guidance that never overrides runtime rules, the operator, or what the user asks, with a personal lesson preferred over a shared one. A session already running is told of a change at its next turn.
  • All-or-nothing rollback — Rollback restores each entry exactly, and refuses while a later approval on the same entry is still applied.

Memory ​

Remember everything that matters, scoped per user and workspace.

  • Multi-user memory — With an engine backend (sqlite_fts or lance_embedded) each user has their own memory store, and one user's fact never replaces another's: a record is identified by its text within its owner's scope. Preferences, decisions, contacts, and project facts are isolated by actor identity. See Memory.
  • Write-back you can check — Every post-turn write-back logs how many facts it extracted, kept and stored, and why it stored fewer; reasoning models extract too. A delegated worker that inherits memory writes the delegating user's, not the workspace's. See Memory.
  • Hybrid recall — Combines lexical full-text search (SQLite FTS5) with semantic vector search (LanceDB) so you find what you need whether you remember exact words or just the concept.
  • Context compaction — When a conversation gets too long, UGENT compresses older turns into a compact summary while preserving key facts and decisions. Compaction is isolated per user.
  • Memory scopes — Configure which memory tiers are active: core (always on), workspace (per-project), or global (cross-project). See Memory.

Message Pipeline ​

Shape every message before the LLM sees it.

  • Message Routing — Detect tags, complexity, or scope; inject context from your knowledge base; and restrict the toolset per rule. Combine detectors, rewriters, and actions into a flexible pipeline. See Routing.
  • Rule Engine — Rules that let a channel message through to the agent, stop it, start a cron job for its sender, or save or compact the sender's conversation, matched on its text, channel, kind of conversation, sender, or whether it was spoken. Boolean logic with all_of, any_of and not. See Rule Engine.
  • Hook system — Register custom hooks at lifecycle points (BeforeAgentTurn, BeforeToolCall, AfterToolCall) to intercept and modify agent behavior. See Security & Firewall.
  • UCTR compression — Reversible tool-result compression stores full tool outputs in a compressed form and restores them on demand, keeping the active context lean without losing information.
  • Context overflow prevention — Automatically manages token budgets so conversations never exceed the model's context window. Older content is compacted or truncated before the LLM request is sent.
  • Context adaptive payload budget — Dynamically adjusts the context payload size based on the model's available window, ensuring maximum useful context without overflow.
  • Monotonic message ordering — Message order is assigned by the database, not by the clock, so an NTP correction, a laptop suspend, or a VM migration cannot reorder a transcript or make a tool result precede its own call.
  • Non-destructive compaction — Compacted and dropped turns stay on disk rather than being deleted. History is readable back in pages, so a summary never means the original is gone.
  • Translation routing — A dedicated routing plugin routes messages to a translation workflow based on language detection, with glossary and reference-text support.

Channels and Plugins ​

Connect UGENT to 13+ messaging platforms and build your own.

  • 13 channel plugins — WeChat, WeCom, Weixin, LINE, Discord, Slack, Telegram, DingTalk, Email, WhatsApp, Salesforce Chatter, Web, and Translation. Each runs as an isolated worker process.
  • Web channel — An OpenAI-compatible HTTP API with SSE streaming, for the web workspace and your own applications: a model and opt-outs per turn, resumable event streams, durable message receipts and conversation snapshots, typed answers to the agent's questions, and keys that confine an application to its own users' conversations. See Web Channel API.
  • Numbered citations — In the web workspace an answer marks each claim with a number that links to its source under the answer: a file at the lines quoted, an exact document version, a database table, or a recalled memory. Passages from the agent's own searches are citable too, a path with spaces is cited like any other, and a citation the page cannot follow shows a warning rather than raw text. See Citations under an answer.
  • Web workspace — A browser workspace on the web channel: answers stream with their reasoning, sources and files; a running turn can be steered, queued behind or stopped, and says what happened; the agent's questions are answered on a card, once; and a conversation picks up where the agent is after a reload, a reconnect or in another tab. See The Web Workspace.
  • Charts, diagrams, maths and code in answers — Fenced chart (Vega-Lite) and mermaid blocks are drawn in place, with their source, fullscreen and SVG, PNG and CSV downloads; $$ formulas are typeset, and code is coloured in 17 languages with a copy button. Each is bounded, so an answer cannot hold the page. See Charts, diagrams, maths and code.
  • Record cards — Rows of a CSV or TSV that an answer cites are shown as cards under it, laid out as a record-types block in the workspace's AGENTS.md says and read from the file each time, never from the model's text. A citation must quote the row's opening words, so a wrong key shows no card rather than the wrong row, and a reader gets cards only from files they may open. See Record Cards.
  • Files in the browser — Folders and files move by drag and drop or a folder picker; a markdown file has an editor and a preview; the editor's height follows its resize bar and is remembered; a text file too large to edit opens read-only, a part at a time. Markdown files an answer produces or links to open in a viewer over the chat. See Files.
  • Multimedia transfer — Images, audio, video, and documents are transferred across all channels with automatic format normalization.
  • Plugin lifecycle — Plugins are supervised processes with heartbeat monitoring, automatic restart, and graceful shutdown. Instance isolation prevents one plugin's crash from affecting others.
  • Plugin setup wizard — Interactive setup for each channel plugin with credential validation and test messaging.
  • Build your own — Use the plugin template to create custom channel or tool plugins in Rust. See Plugins guide.

Developer Experience ​

Tools that make working with UGENT fast and ergonomic.

  • LSP integration — Go-to-definition, find references, diagnostics, hover, and document symbols from real Language Server Protocol sessions. Supports Rust, Python, TypeScript, Go, Java, and more. Results are distilled as compact pointers, not raw payloads.
  • TUI mode — A full terminal user interface with chat history, streaming responses, tool-call visualization, model picker, and debug panel. See TUI Mode.
  • REPL and execute modes — Run UGENT headless for scripting and automation. ugent -x "your query" runs a single command and exits. See REPL & Execute.
  • Daemon mode — Run UGENT as a systemd service for production deployments. Auto-reloads config on file changes. See Runtime & CLI Flags.
  • Herdr integration — Terminal multiplexer integration with pane state reporting, tool metadata, and toast notifications.
  • Workspace switching — Use /cd <path> to switch workspaces at runtime without quitting. ugent --workspace <path> selects the workspace at startup.
  • Smart mascot — A status-aware terminal mascot that reflects agent activity (thinking, tool running, idle, error) for at-a-glance monitoring.
  • Setup hub — Interactive /setup wizard guides you through LLM provider configuration, audio setup, embedding model selection, context client defaults, and health checks.
  • Web activity feed — Real-time stream of sub-agent assignments and tool execution events, available via the web plugin for monitoring dashboards.
  • Tool output projection — Controls how much of each tool's output is visible to the LLM versus stored in history. Keeps the active context lean without hiding information the agent needs.

Scheduling and Automation ​

Set it and forget it — UGENT runs on your schedule.

  • Cron jobs — Schedule recurring tasks with full cron syntax, or let a rule start a job on demand for whoever asked. Jobs run in the background and report results via your configured channels. See Runtime & CLI Flags and Starting a Workflow.
  • /loop and /goal — Self-paced autonomous loops. /loop runs a task repeatedly on a timer; /goal drives toward a success criterion with progress reporting, and survives a restart, paused. See Autonomous Runs.
  • Verification gates — A goal ends on the agent's own judgement, which can be confidently wrong. Configure your project's checks as a gate and every completion claim is checked against the workspace as it stands and recorded. The goal completes only when every check passes, and a failure feeds the real error back for another attempt instead of a bare rejection. Reruns are skipped when nothing changed, except on the final attempt, which always runs for real so a skip can never be why a goal is declared blocked.
  • Daemon config auto-reload — The daemon polls config files every 5 seconds and reloads on any change — no restart needed. Content fingerprints detect creation, removal, and edits.

Skills ​

Load specialized behaviors on demand.

  • Skill registry — Skills are markdown files that inject specialized instructions, tool guidance, or workflow templates into the agent's context. Loaded from workspace-local and global directories.
  • Claude Code compatibility — UGENT can load and execute skills designed for Claude Code, widening the available skill ecosystem.
  • Skill overrides — Configure per-skill trust levels, shell execution policy, and firewall rules. See Skills.

Multi-Tenancy and Administration ​

Manage multiple users, workspaces, and tenants.

  • Per-user model selection — Each user picks their preferred model from an allowlist. Selections persist and are isolated, and a model named on one request runs that turn alone.
  • Multi-user memory isolation — With an engine memory backend, memory, context compaction, and session state are scoped per user. The default legacy_markdown backend shares long-term memory across the workspace, and says so in the log.
  • Per-caller defaults — [caller_defaults."<issuer>"] applies code-context and memory opt-outs, and a default model, to every turn from one federated caller, with no change on the caller's side. See Service Callers.
  • Workspace isolation — Each workspace has its own config, plugins, skills, cron, and memory. Switch workspaces with /cd without cross-contamination.
  • Tenant Console — A standalone Next.js web console for managing the UGENT context engine in multi-tenant deployments. Super admins manage the full tenant lifecycle (create, suspend, delete, rotate keys) through a private management API. Tenants self-serve their own API keys, codebase indexing, and BYOK (bring-your-own-key) secrets through a public self-service API. The browser never holds an engine credential — every call happens server-side. Deploy alongside the engine via Docker.
  • Enterprise SSO — A centralized SSO broker authenticates users against your corporate OIDC identity provider (PingFederate, Entra, Okta) and hands the verified identity to ugent-web through a single-use, 30-second handoff code. Federated and password logins resolve to the same actor, so memory and per-actor access control carry over. External applications can pass federation_issuer/federation_subject so the same person shares one memory scope across CRM, portal, and helpdesk. The broker stores no passwords and assigns no roles; SAML has a built seam but no implementation yet. See SSO & Federated Identity.
  • Per-conversation isolation — Each conversation runs in its own session with independent state, memory scope, and tool registry. Conversations never interfere with each other, even under the same user.
  • RBAC — Role-based access control with granular permissions per domain (users, roles, documents, translation, workspace management). In the web workspace, administrators add people, departments and groups, tick each role's permissions and grant models per department and group. See People and Permissions.
  • Document translation — The web workspace translates pasted text or a library document with a person's glossary entries and up to four reference translations, as a server-side job that survives closing the page. See Document Translation.
  • Branding and the chat widget — A theme studio sets a deployment's colours, fonts and logos with a contrast report, and a script tag puts the chat behind a launcher on a page served from the workspace's own origin, or from a site listed under the published widget's allowed sites, which may frame the chat and nothing else. See Branding and the Embedded Widget.
  • Document administration — The tenant console's Documents area turns a tenant's document catalog on and off, edits document types and the rules that assign them through a preview-and-activate journey, and lists what needs a person: tied versions, documents missing from a scan, dated changes that have not reached search. Curators add metadata or say a field has no value; administrators hold, transfer and purge. See Documents.
  • Per-actor and per-group clearances — A clearance is one level id on an actor or a group, and a person's is the highest of their own and their groups'. An actor nobody has cleared gets the lowest level, as does a request that asserts no actor; administrators are bound by their own clearance unless the scheme opts them out. The tenant console shows the scheme actually in force, levels in rank order, and edits only the settings that cannot reclassify anything already stored.

Data Lifecycle ​

Keep your disk clean automatically.

  • Automatic disk cleanup — Old session data, compressed tool outputs, and stale checkpoints are cleaned up on a configurable schedule.
  • Transcript retention for service callers — Delete a service caller's transcripts once a conversation has sat unused for 15 minutes to 29 days: messages, answers, events and sessions, overwriting the space a delete frees (pages an earlier rewrite freed, and the write-ahead log, can hold text until reused). Covers named service subjects whose turns use no tools, including turns that were stopped or failed, unless a daemon restart cut the turn. See Service Callers.
  • Event log ageing — Stream events older than 30 days are deleted alongside the 50,000-row cap, and [session] retention_days sets the window a session_cleanup job uses. See Service Callers.
  • Session management — Sessions can be listed, resumed, checkpointed, and restored. Checkpoints capture the full agent state at a point in time for crash recovery.
  • Migration safety — Database schema migrations are validated at startup with a regression manifest. Unknown or inconsistent schemas are hard errors with actionable guidance.

Runtime and Performance ​

Built for speed and reliability.

  • Multi-core tokio runtime — N worker threads (default = CPU count) with 153+ async tasks across cores. CPU-bound work is offloaded to blocking threads to never stall the async runtime.
  • Runs anywhere — SSH, tmux, zellij, Herdr, Ghostty, Warp, Alacritty, iTerm2, WezTerm, Windows Terminal + WSL. OSC 52 clipboard over SSH.
  • Unified logging — A single logging facade routes messages to file, stderr, and the TUI debug panel simultaneously.
  • Graceful startup — Two-phase bootstrap reads config before the tokio runtime starts. LLM config errors are warnings, not crashes — the agent starts and you fix config interactively.
  • Clean reloads — A reload or shutdown stops the running orchestrator before anything replaces it, so the old runtime never resumes, accepts or saves work beside its replacement. See Runtime & CLI Flags.

Released under the Private Beta License.

Copyright © 2026 UGENT Team