The backend language for agents to write and people to trust.

The common holes agents leave are compile errors

In most backends, the rules for who may see what are spread across middleware, query code and the reviewer's memory. An agent can miss any of them. In Jadpo those rules are part of the program, so the compiler checks them.

entity Note {    id: Uuid    owner_id: User.id { … }    reviewer_id: User.id { … }    text: NoteText    appraisal: NoteText {        policy: {            read: [reviewer_id]        }    }    policy: {        read: [owner_id, reviewer_id]    }}type NoteView = Output {    pick: [Note.id, Note.text, Note.appraisal]}query find_note(note_id: Note.id) fails NoteNotFound -> NoteView {    from: Note    where: Note.id == note_id    missing: NoteNotFound}

entity Article {    id: Uuid    title: ArticleTitle    policy: {        read: [Access.authenticated]    }}

The compiler also refuses a secret, such as an API key in the app's settings, used where it could leave the server: see configuration.secret_flow. Every route needs sign-in unless it says otherwise: see routes are signed in by default. And an app can't call an outside service it hasn't declared, because Jadpo has no general HTTP client. Each service comes in as a typed package: see external services.

When the fix is your call, the error says so

Some errors can only be fixed by loosening who may see or change data. The compiler can't know whether you want that, so it marks the next step (human): the decision is yours, and the prompt below, which you paste into your agent, tells it to stop and ask you. If your agent loosens access anyway, jadpo check fails until a person adds an acceptance: a short file in the change that says why they accept it.

routes Articles {    prefix: /articles    GET /{article_id: Article.id} {        authentication: RouteAuthentication.noneadded by your agent        output: ArticleView        run: find_article(article_id)    }}

What your agent actually writes

One feature, start to finish: a customer orders a cake. The app charges the card, stores the order and announces it with an event, a message other parts of the app can react to. These are real files from a small shop example, checked with the rest of its project. Only their imports are left out.

/// How many cakes one order is for: the oven holds twelve.type Quantity = Int {    min: 1    max: 12}

/// An amount in pounds, held as whole pence.type Sterling = Money {    currency: Currency.gbp    rounding: Rounding.half_even}

routes Orders {    prefix: /orders    // The action's failures become HTTP errors by their kind (404, 422) and    // are listed in api/main.jadpo_record. One it left undeclared wouldn't compile.    /// Places an order.    POST / {        input: PlaceOrder        output: OrderReceipt        status: SuccessStatus.created        run: place_order(input, current_principal.user)    }}

/// What placing an order takes; a quantity outside 1 to 12 never gets in.type PlaceOrder = Input {    cake_id: Cake.id    quantity: Quantity}/// Charges the card, records the order and announces it.action place_order(    input: PlaceOrder,    customer: Principal.user) fails CakeNotFound, CardDeclined -> OrderReceipt {    var cake: Cake = attempt orderable_cake(input.cake_id)    // Cakes in grams, box in kilograms, packing in pounds: one `Mass`.    var weight: Mass = cake.weight * input.quantity + 1.2kg + 3lb    // Dividing a `Mass` by 1kg gives a plain number: how many kilograms.    var kilograms: Decimal = weight / 1kg    var per_kilo: Sterling = Sterling(money.from_minor(200, Currency.gbp))    var goods: Sterling = Sterling(cake.price * input.quantity)    var postage: Sterling = Sterling(per_kilo * kilograms)    // `* 120%` adds 20% VAT to the goods and the postage.    var total: Sterling = Sterling((goods + postage) * 120%)    // The provider's decline becomes this app's own failure.    attempt pay.charges.create(        AcmePay.ChargeRequest {            amount_minor: money.minor(total)        }    ) {        declined_card: CardDeclined    }    // The order and the event commit together, or not at all.    var order: Order = Order.create {        set: {            customer_id: customer.id            cake_id: cake.id            quantity: input.quantity            total: total        }    }    emit OrderPlaced {        order_id: order.id    }    return OrderReceipt {        id: order.id        total: order.total    }}

entity Order {    id: Uuid    customer_id: Customer.id {        on_delete: OnDelete.restricted    }    cake_id: Cake.id {        on_delete: OnDelete.restricted    }    quantity: Quantity    total: Sterling    policy: {        create: [customer_id]        read: [customer_id]    }}

A whole language, with the backend built in

Jadpo isn't a linter over TypeScript. It's one language and one compiler, and the parts of a backend you'd normally choose and connect are already in it. There's no framework, ORM, validation library or job queue to pick, so there's nothing for an agent to connect wrongly. Everything below works today.

• Strict types

  Named types with limits (a number from 1 to 12, say), a separate ID type for each record, enums, units that convert exactly, and money in any ISO currency. Types

• HTTP APIs

  Typed routes with one input and one output, an OpenAPI document for each API, and safe retries and time limits on every route. HTTP

• Data

  PostgreSQL tables with references and constraints, migrations checked against the schema, indexes worked out from your queries, full-text search, and every write in a transaction. Data

• Sign-in and access

  Sessions, tokens, API keys for other services, magic links, passkeys, and sign-in through a provider such as Google. Then who may see what: owners, roles, each customer's data kept apart on one backend, and permissions on single fields. A change that loosens access fails the check until a person accepts it. Identity

• Outside services

  Each outside service is a typed package, made by hand or imported from an OpenAPI document. Webhooks, recorded responses and generated fakes for tests, with a package manager and a lock file. Integrations

• Background work

  Events saved in the same transaction as the data, subscribers, retries, schedules, and batches that pick up where they stopped. Jobs and events

• Settings and time

  Typed settings and secrets, time zones, recurring times and translations. Configuration

• Testing

  Tests for actions, routes and schedules, a real database for each test, a clock you control and a fake for every outside service. Testing

• Tooling

  A formatter that decides all layout, editor support through a language server, --json on every command, and the same shape for every error. Tooling

• AI in your app

  Prompt files the compiler checks, typed answers from the model, streaming, token budgets, and similarity search with pgvector. AI

Fast, and measured in the open

Apps compile to native code, or to WebAssembly for Cloudflare Workers, tested here in workerd, the open-source runtime behind Cloudflare Workers, running locally. The figures come from one app written twice: in Jadpo, and in strict TypeScript with Hono, Zod, Drizzle, CASL and JOSE. It manages todos, but it's built like a real backend, not the five-minute demo.

• Sign-in

  Browser sessions, API tokens, keys for other services that call it, and tokens from an identity provider. Every route needs sign-in except the health check.

• Permissions

  Each person reads and changes only their own todos. A request with a missing or forged credential, or two that disagree, is refused.

• Data

  PostgreSQL with migrations, edits that change only the fields sent, and paged lists that stay stable while the data changes.

• Reminders

  A schedule finds overdue todos, and background jobs send reminders through a mail service, safely if a job runs twice.

• Deletes

  A deleted todo is kept for 30 days, then a purge job removes it in batches.

• Running it

  Typed settings and secrets checked before the app starts, rate limits on every caller, and a readiness check.

Before anything is timed, both versions must pass the same 44 tests over HTTP, covering everything above. The timed requests read, add and list todos with all of it switched on: sign-in, permission checks, rate limits and transactions. Every response, and every row saved, is checked against what it should be. PostgreSQL 16 runs on the same machine. Each figure is the median of three rounds, and lower is better.

• ▲Jadpo is slower to start under workerd: 70 ms against TypeScript's 65 ms.
• ▲Jadpo on workerd is slower at background work than TypeScript on Bun. It delivers 2,239 events a second against Bun's 4,017, and each scheduled run takes 55 ms at p95 against 29 ms. When each event calls another service, Jadpo delivers 1,435 a second, 63% of what Bun manages on the same test.
• ▲Read with care. A native Jadpo app uses a thread per core, while Bun, Node and workerd each use one thread. So compare CPU per request first: the extra threads help native's latency too. Every run was on one shared Apple M1 Pro, and each test client waited for an answer before sending its next request, so these figures don't show production capacity.

From Jadpo's benchmark summary, 29 Oct 2026. How each one is run, and how to reproduce it.

Change one thing, and the whole app is checked again

An agent sees the file it's editing, not everything that depends on it. Any compiler checks types across files. Jadpo's also checks three things that usually break quietly: the failures callers must handle, the database schema and the public API.

Fair questions

The ones a sceptical reader asks first, answered plainly.

Try it with your agent

Jadpo is new, so your agent learns it from these docs. The prompt has your agent install the CLI and start a project, so read it before you paste it.

Help me try Jadpo, an experimental language for AI-written backends. It's new and changes between versions, so don't rely on what you remember about it. Start at https://jadpo.dev/llms.txt and read https://jadpo.dev/docs/primer.md before writing any Jadpo.

Install the Jadpo CLI as https://jadpo.dev/install.md describes, start a project with jadpo new, then run jadpo check and jadpo test in it.

When an error's next step ends in (human), stop and ask me before changing anything. For other errors, read the error's page, fix it, and tell me what the compiler caught.