Apps are how agents get work done.

Core apps

The foundations.

The apps agents reach for first. Storage for files, jobs for scheduling, code for repos, CRM for contacts. Other apps build on top — image-studio writes to storage, media catalogs storage, jobs schedules across them all.

More first-party apps

Productivity, channels, observability, and a few specialised utilities — all maintained by Apteva.

One-click install

Three steps to a new capability.

What an app can be

Six surfaces. Mix any combination.

An Apteva app is a manifest plus whatever surfaces it wants to provide. Some apps are pure tool packs. Others are full sidecars with their own UI, channels, and workers. These are the surfaces for server-installed apps — hardware-native tools register directly through the embeddable core (covered below).

Across every domain

Apps for every kind of work.

Some apps are full UIs you watch. Some are MCP tool packs the agent calls. Some are channel adapters, hardware drivers, or background workers. Across the marketplace they cover business operations, personal life, robotics, industrial control, financial markets, and creative work — anywhere persistent agents have a job to do.

Examples of what fits the marketplace. Apteva ships the platform and the first-party set above; everything else comes from the ecosystem and from anyone who builds with the SDK.

Stack apps. Run an operation.

A few apps, an autonomous team.

Apps compose. Install a CRM, a task board, a Slack channel, a billing integration — the agent uses all of them, coordinated, around the clock.

Beyond the server

Same agent runtime. Cloud, edge, or robot.

On a server, apps install through the marketplace as sidecars and static UIs. On a robot, IoT gateway, or industrial controller, the core compiles in directly — and the "apps" are native Go tools the agent calls. Same continuous loop, same workers, same self-pacing. The deployment changes; the agent model doesn't.

See Embeddable Core → for the hardware path.

Build your own

An SDK, a manifest, a sidecar.

Apps depend on the public Go SDK only — never on apteva-server internals. Declare what you provide in apteva.yaml, implement the surfaces you care about, ship a binary or a static bundle. The platform handles the rest.

Apps are Go binaries. They start in milliseconds, eat single-digit MB of RAM, and run at native speed. Stack a dozen apps on the same server — the footprint stays small.

package main

import sdk "github.com/apteva/app-sdk"

type App struct{}

func (a *App) Manifest() sdk.Manifest { return loadManifestFromYAML() }
func (a *App) MCPTools() []sdk.Tool {
    return []sdk.Tool{{
        Name: "hello",
        Handler: func(ctx *sdk.AppCtx, args map[string]any) (any, error) {
            return "hi from " + ctx.Manifest().Name, nil
        },
    }}
}

func main() { sdk.Run(&App{}) }