What the agent can do

The agent in the chat is not answering from a description of your project. It reads it, searches it, edits it and runs commands in it — using a fixed set of tools that it must ask for by name, and that Semantix executes on your machine.

Knowing that list is most of knowing what the agent is capable of.

The tools#

Reading and searching — these run without asking you.

Tool	What it does
read_file	Reads one file, optionally just a line range
read_files	Reads several files in one call
list_dir	Lists what's directly inside a folder — one level, not recursive
code_search	Fuzzy, relevance-ranked search across the indexed project
code_grep	Exact regex or literal search, with file:line:col and the enclosing symbol
symbols	Finds where a function, class or type is defined
references	Finds everything that calls or imports a symbol
check_errors	Runs your real type-checker — tsc --noEmit, cargo check — and returns the diagnostics

The last five are the index doing work the model would otherwise pay for with tokens. code_grep returning the enclosing function for every match is the part no plain search gives you.

Changing things — these can ask first, depending on your permission mode.

Tool	What it does
write_file	Creates or fully replaces one file
edit_file	Targeted edits inside an existing file
create_dirs	Creates folders
move_path	Moves or renames
copy_path	Copies, recursively
delete	Deletes files or folders
run_command	Runs a shell command

Remembering — with memory switched on, the agent also has tools of its own for it: recall_memory and carve_memory to read and write what it knows, search_conversations and read_conversation_message to look through past chats, pin_standing_order and unpin_standing_order for rules about its own conduct, and write_whiteboard to leave a note for the project's other agents. None of these ask; you see each call as a card.

→ Memory

Your own tools — anything you've added under Settings → Tools, called by name like the rest. Each one carries a danger level you set, and the gate treats it like a read, a write or a shell command accordingly. And any native tool can be switched off there, in which case the model isn't told it exists.

→ Tools

The permission mode#

Next to Send sits a chip reading Manual, Edits or Full. It's your standing posture toward the tools in the second table — global to this machine, persisted, Manual by default.

Mode	Asks for
Manual	Every write, delete and command
Edits	Deletes, and any command that isn't light
Full	Deletes, and critical commands only

Commands are sorted into three tiers by what the command actually is, not by where it came from. Light commands read or build inside the working tree — git status, git diff, tsc, cargo test, npm test, ls, grep, ps. Heavy commands change something beyond the tree or reach out — git commit, git push, npm install, curl, cp, kill, running a script. Critical commands are the irreversible, privileged or arbitrary ones — rm, dd, sudo, a bare bash -c, python -c, git push --force, git reset --hard, git clean -f — and anything Semantix can't parse. A critical command asks in every mode, Full included — you can still say yes, but you'll be asked. A command Semantix has never heard of counts as heavy, never light.

The same tiering reads a whole shell line, so a rm hidden behind a pipe in cd x && ... | rm is still critical.

Which lane you're on#

The gate is the same on every model. On a model from a connected provider or a custom endpoint, Semantix executes the tools above itself and asks according to your mode. On Claude Code, the Claude Agent SDK runs its own tools — Read, Write, Edit, Bash and the rest — plus the Semantix search and memory tools; its writes and edits go through the same card as write_file and edit_file, and its Bash calls are tiered exactly like run_command. Reads, searches and web tools run unasked on both lanes.

Asking permission#

When the gate does ask, the conversation stops. The whole transcript frosts over and an approval card pins itself to the bottom of the panel so you can't scroll past it.

The card shows Permission required, a class badge — WRITE in amber, DELETE in red, SHELL in violet, CUSTOM TOOL in teal — and the tool name. A critical command adds a red CRITICAL badge. Below that, one line describing the target: $ npm run build for a command, the path for a file operation, src → dst for a move or a copy. A quiet line at the right tells you which mode would have skipped this prompt — Skipped in Edits and Full mode, Critical command · asked in every mode — which is how most people discover the chip.

Three buttons: This turn, For session, and Deny.

This turn allows every action of that class for the rest of the turn — one instruction that touches five files is one approval, not five. Deny refuses; the agent is told plainly that you declined and instructed not to retry, so the turn ends cleanly instead of hanging or nagging.

For session is the one to understand properly:

Once answered, the card collapses to one line — write_file · allowed for this turn, or denied — that stays in the transcript.

The card shows paths, never content — approving a write means approving the destination sight-unseen; read the diff afterwards.

The undo point#

The first approved change in a turn triggers an automatic workspace checkpoint. That's what the Restore control on a message rolls back to — see Conversations and history. It's taken on every lane, Claude Code included.

It's best-effort. If taking the checkpoint fails, the tool still runs; you lose the undo point, not the work.

Watching a tool run#

Each call renders as a card in the transcript: an icon, a friendly name, and the filename it's working on — clickable, it opens that file in a tab. Above it, one line in the agent's own words says why. The icon is the status: it pulses in your theme's secondary colour while the tool runs, turns red if it failed, and goes faint once it has landed.

The card appears before the arguments finish arriving, and fills in as they stream. A file write resolves into a syntax-highlighted diff. An edit shows +added / -removed before it lands. Deletes, moves and copies resolve into a list of paths, each marked ok or failed.

run_command is one line. The command sits in a small mono pill, trimmed for reading — a leading cd <dir> && or NAME=value prefix is peeled off and your home folder shows as ~. Click the pill to copy the command exactly as it ran. While it runs, the seconds tick at the right edge beside a Stop button that kills the process. When it finishes the line settles to a verdict: a clean exit shows only the time and a dot in your accent colour; a non-zero exit shows exit 1, a timeout timed out, a kill stopped. A chevron then opens the output, so a failed build's error is there to read.

What you can't do is type into it: a command that stops to ask a question will wait until it times out or you stop it.

Commands that don't end#

A command that would never exit on its own — a dev server, a file watcher, tail -f — is started detached automatically: the tool answers in about a second with the process id and a log path, and the turn goes on. The process keeps running until it exits or Semantix closes.

The agent can also ask for a command to run in the background explicitly. Then the turn ends at once, and the job reports back when the process exits — or when its output has been quiet for 4 seconds, which is what lets a dev server say "I'm up" without hanging the conversation. The report arrives as a new message carrying the last 8000 characters of output.

MCP servers#

Settings → MCP Servers adds tool servers — remote HTTP/SSE endpoints or local stdio commands. Their tools are offered to every model, namespaced mcp__<server>__<tool>, and the catalogue is re-read on every message you send, so changes apply without a restart.

MCP tools execute on your machine, in Semantix's own MCP host. What reaches the model provider is the tool's name, description, schema, and the arguments a call uses.

→ MCP servers

The limits#

Shell commands	Any program on your PATH, by bare name — the gate is the control, not a list
Working directory	Must stay inside the project
Command timeout	60 seconds default, 600 maximum
Tools with no project open	None — the agent is told there's nothing to work in