---
title: Subako Functions
description: Your own tools, run by Subako as WebAssembly.
sidebar:
  label: Overview
---

An agent is only as useful as what it can reach. MCP servers reach systems that already exist; **Subako Functions** are for the tools that do not exist yet — parse this file, build that spreadsheet, call your billing API the way your team calls it, check an order against your own rules.

A **function package** is a WebAssembly module and a short manifest. You upload it to a workspace, grant it to an agent version, and from then on every tool the module offers is a tool the agent can call. Subako runs each call in a sandbox of its own, next to the session, with the session's files at hand and only the network access you granted.

![A session's conversation: asked about an uploaded quarterly review, the agent called convert_to_markdown on the function anydoc, and answers from the document](/blume-assets/content/docs/_images/en/session-function-calls.webp)

## Why a function

- **No server to run.** There is nothing to deploy, scale, or keep up: Subako starts the module for a call and stops it after.
- **Your language.** The [Rust](/functions/rust), [TypeScript](/functions/typescript), and [Go](/functions/go) SDKs turn ordinary functions into tools, with their input schemas generated from your types. Any other language that builds for WASI preview 1 can speak the [ABI](/functions/abi) directly.
- **Isolated by default.** A call has no network unless its grant gives it one, and then only to public `https` hosts it allows. Credentials are attached on the way out from the session's [vaults](/console/vaults); the module never sees them.
- **Data stays out of the context.** Functions work on files in the session's [Session Volume](/functions/runtime#the-session-volume), so a large document or export never has to pass through the model. See below.
- **Ships its own files.** A package carries [assets](/functions/runtime#package-assets) — templates, fonts, reference data — that every call reads at `/package`.
- **Versioned with the agent.** Every upload is a new immutable version, and an agent version pins one or follows the latest. Publishing a fix never changes a session already running.

## Working on data without filling the context

Everything a tool returns is put in front of the model, and the model's context is both limited and paid for by the token. An agent that loads a 200-page contract, a year of order exports, or a whole repository into its context runs out of room — or spends most of its budget re-reading data it only needed to look at once.

Functions avoid that by working on files instead. Every session that uses functions has a **Session Volume**: a filesystem the session's functions share, which your app and the people in the console can read and write too. A function reads its input from the volume and writes its output back, and the model sees only what it needs to decide the next step: a path, a count, a summary, the three rows that matter.

- anydoc converts a long PDF to a Markdown file on the volume; the agent then searches that file with `files` and reads only the matching sections.
- A function downloads a 50 MB export straight to `/volume/tmp`, aggregates it, and answers with the totals — the export itself never enters the conversation.
- One function's output file is the next one's input, so a chain of steps — fetch, convert, analyze, render — moves data from tool to tool without the model carrying it in between.

The files stay after the call, so a person can download the result from the session's **Session Volume** tab, and your app can read it over the API.

## Functions or a sandbox?

A [sandbox](/sandboxes) gives the agent a whole Linux machine and runs whatever commands it writes. A function runs code you wrote, in a fresh sandbox per call, with no network unless you grant it and its credentials kept in a vault. Functions are safer, cheaper — billed only while a call runs — and their results land on the Session Volume, where every other tool can use them. Reach for a sandbox only when the work needs a real Linux userland, such as building and testing a codebase; [Sandboxes](/sandboxes#start-with-a-function) compares the two, and lists the functions that already cover Python, shell scripts, JavaScript, and documents.

## How it fits together

1. **Build a package**

    Write tools with an SDK and build them into `module.wasm`, beside a
    `subako-package.json` naming the package — or build one of the
    [examples](/functions/examples). [Write your own](/functions/write-a-function)
    starts from a template in each language.

2. **Upload it to a workspace**

    From the console's **Functions** page, or with `subako function create`.
    Subako runs the module once to read the tools it offers, and shows them
    with their parameters.

3. **Grant it to an agent**

    In the agent version editor, under **Function packages**: which version,
    how long a call may run, which hosts it may reach, which credentials it
    gets, and whether a call asks first. See [Granting functions](/functions/granting).

4. **The agent calls it**

    The model sees each tool's name, description, and input schema, and calls
    it like any other tool. The session's conversation shows the call, its
    arguments, and what it answered.

## Platform packages

Two packages come with Subako and need no upload:

| Package | What it does |
| --- | --- |
| `files` | Lists, reads, searches, writes, moves, and removes files in the Session Volume, and shows the model images it reads. |
| `http` | Sends HTTP requests, with bodies to and from volume files, under the grant's network and credentials. |

They are granted the same way as your own packages — see [Platform packages](/functions/platform-packages).

## Start here

**[Quickstart](/functions/quickstart)**

Teach an agent to read Word and PDF files with the anydoc package.

**[Examples](/functions/examples)**

Python, Bash, JavaScript, Typst, Excel, PowerPoint, and more, as packages.

**[Calling APIs](/functions/calling-apis)**

API clients whose keys stay in a vault, with GitHub as the example.

**[Granting functions](/functions/granting)**

Versions, timeouts, network, credentials, and approvals.

**[ABI reference](/functions/abi)**

Write a package in C, Zig, AssemblyScript, or anything else.