Projects & Tool Loop
Projects is where you work with a model on something that takes more than one answer: a conversation with files, a workspace, and a tool loop that can browse, read, write and run code, under the policy you chose.
Projects needs Enable AI. See machine learning.
| Open it with | |
|---|---|
| Kaba menu → Projects | |
/projects in the omnibar | Aliases /p, /proj, /chat |
/ask <text> | Opens a project with your text ready to send |
[todo: add screenshot of Projects and of parts the project sidebar, the conversation thread, the composer, the side panel with a file preview.]
A project
Section titled “A project”A project has a conversation, the files you attached or the model produced, and a governing policy.
- Sidebar: your projects, which you can group, rename, export and delete.
- Thread: the conversation. Edit or delete a message; generation statistics are shown per reply.
- Composer: type a message, attach files (or paste and drag them in), and press Enter.
- Side panel: previews and edits files the run produced.
- Voice: dictate with the microphone, and have replies read aloud.
In the composer, # mentions do things: #<peer> sends this message to a specific device, and #fresh resets the workspace.
Policy and compute
Section titled “Policy and compute”Each project runs under a policy. By default it follows your account’s active policy; pick another from the project’s settings. On a fleet-managed device the available policies come from your organisation. The policy decides the device, base model and adapter together.
A project can also choose its own compute: which device and which container its file, code and execution work runs in. This overrides the policy’s choice for this project only, unless the policy has Prevent overriding policy settings turned on, in which case the controls are locked and say so.
[todo: add screenshot of a project’s settings and of parts Project policy, Compute (peer & container), the locked-by-policy notice.]
The tool loop
Section titled “The tool loop”When a task needs more than words, the model works in a tool loop: it picks one tool, Kaba runs it, the result goes back, and it picks the next. The loop is bounded and ends; it holds no standing authority.
Tools are grouped by what they touch.
| Group | Tools |
|---|---|
| Read the web | get_page, search_web, resolve_site, fetch_page, read_page, inspect_page, find_in_page, crawl, list_frames, switch_frame |
| Act on the web | open_pane, navigate, open_background, close_background, close_pane, click, scroll, type, press_key, hover, drag |
| Shopping | extract_products, collect, rank_candidates, cart_link |
| Files | list_files, grep_files, read_file, outline_file, read_symbol, map_files, stat_path, write_file, edit_file, replace_lines, make_patch, apply_patch, clear_file, delete_file, deliver_files |
| Code | run_script, check_deps, find_lib, scan_code, profile_run, new_project |
| Flow | select_flow, write_plan, use_playbook, use_skill, make_flowchart, simulate |
| System | run_host_command, gpu_info, delegate_task |
| Memory | search_docs, search_memories |
| Core | say, done |
The catalog is fixed in code. A policy can remove tools, restrict them to certain surfaces, re-describe them and order them. It cannot add one.
What you see
Section titled “What you see”While a run is active the frame is marked as being driven by Kaba. The thread shows each step, and the results appear as cards:
- File cards and diffs for what was written or changed.
- Exec runs for commands, with their output.
- Simulations when the model modelled something before doing it.
- A flow indicator showing which phase the run is in.
Stop ends a run at any time.
[todo: add screenshot of a tool run and of parts step-by-step trace, a file card, a diff, an exec run card, the flow indicator, the Stop button.]
Limits
Section titled “Limits”| Limit | Value |
|---|---|
| Steps per run | The policy’s Max tool steps, up to 400. |
| No progress | A run ends after ten asks that achieve nothing. |
| Time | Every run ends at 30 minutes. |
| Commands | Per the policy: Ask, Auto-run for read-only commands, or Off. |
| Network in the sandbox | Per the policy: Off, on request, or always. |
If a task needs a command the container does not have, Kaba says so (Limited build sandbox) rather than failing obscurely. Choose a container image that includes it under Settings → Containers.
Steer control
Section titled “Steer control”Small models make a particular kind of mistake in coding tasks: they repeat themselves, or write a file that does not parse. Steer control is the set of recoveries for that. All are on by default, and each can be turned off per policy.
| Control | Effect |
|---|---|
| Candidate buffer | A whole-file write that fails its syntax check is not kept; the previous version is restored. |
| Best of N | When stuck, sample several candidates, check each with a dry run, and write the first that passes. |
| Tabu | Content that already failed is rejected before it runs again. |
| State view | Each step’s prompt is built from the current state, with older steps condensed. |
| Stuck ladder | One escalation path for any stuck state: resample, start fresh, best of N, then halt. |
| Impact | Shows other files’ lines that use what just changed. |
| Fix memory | Remembers which change fixed which error, and offers it the next time. |
| Localize | For a crash, scans the source for places that can panic and shows them before any edit. |
A flow is a sequence of phases for a kind of task. Each phase is a goal: the tools on the menu, a condition that says the phase is done, and a hint. The model chooses freely within a phase; the phase only narrows the menu. A small menu is the main lever for accuracy.
A flow engages when the task matches its description and the tools it needs are available. Conditions are checked against things Kaba can observe (the address, the page text, which tools have run), never against what the model says it did.
Flows travel with a policy: export a policy and its flows go with it. The format is in the file formats reference.
Toolbench
Section titled “Toolbench”Toolbench shows a policy applied tool by tool: what the loop may use, what is locked, and why. Open it from the Kaba menu, with /toolbench, or from a policy or project with Toolbench →.
Use it to:
- turn tools off for a policy, everywhere or on one surface;
- rewrite the description the model sees for a tool;
- require an order (a tool may only run after one of a set of others);
- create and edit flows in a graph: add phases, choose each phase’s tools, and set its unlock conditions;
- copy a flow to another policy;
- watch a run move through a flow.
What Toolbench edits is stored inside the policy, so it is exported and imported with it.
[todo: add screenshot of Toolbench and of parts the tool list with locks and reasons, the flow graph, the phase editor with unlock conditions, Copy to policy.]
Skills and playbooks
Section titled “Skills and playbooks”Two tools let a run draw on prepared knowledge: use_skill for a described workflow, and use_playbook for site-specific steps. Kaba does not load third-party tool catalogs; new capabilities arrive as first-party tools.
On a headless node
Section titled “On a headless node”The same loop runs inside kabactl, so a run can execute on a server with no client attached, and a run can hand part of its work to a peer with delegate_task.
Related
Section titled “Related”- Machine learning for policies, models and training
- Security for how runs are contained
- File formats for
.kabap, overlays and flows