Faster Betty

Features · Private Beta

Every Betty surface. One approval gate.

Faster Betty talks to the same control planes your builder does — the Meta API, My Betty, the Block Store, the classic builder, and the Data API. It reads them freely and writes only what you signed off, one plan at a time.

The contract

Inspect. Propose. Approve. Apply. Verify. Receipt.

Read operations run immediately. Write operations become one signed, ordered proposal bound to you and to that application, executed step by step in the order you read, then checked back against the live metadata.

  1. 01Private Beta

    Read the whole app. Approve nothing.

    Models, properties, relations, Actions and their step trees, auth profiles, roles, per-model permissions, compile state, publish state — read live from the Meta API, My Betty, Block Store, and the classic builder through cataloged operations. Reads never ask for approval, because reads never change anything.

    Scenario

    Which Actions write to Invoice, and who can run them?

    The agent resolves the Action list and the per-model permissions from the connected app's own metadata and answers with the roles attached — not from a stale export, and not from a guess.

  2. 02Private Beta

    One signed plan. One approval. Exactly once.

    A change request comes back as one ordered, plain-language plan bound to you and to that one application. Approval is verified against the plan's own signature, actor and app binding, expiry, and canonical hash, then burned: a replayed or concurrent approval is refused. Every step carries its own scope — surface, exact operation, target model, record bounds — and a step that falls outside it stops the run instead of improvising.

    Scenario

    Add a status property to Order and give Support read access to it.

    Two steps, displayed exactly as they will run. Approving executes those two and nothing else; the same approval cannot be replayed to run them twice.

  3. 03Private Beta

    Blueprints that compile, publish, and prove themselves.

    The build engine reconciles a whole-app blueprint — models, properties, relations, Actions with variables, nested steps, paths and functions, auth profiles, roles, additive model permissions — against what the app already has, deciding create, reuse, or update per resource. Compile and publish run through typed adapters that pause rather than guess when a provider contract is unproven. Final verification reads the live metadata back and emits a signed, safe-field receipt.

    Scenario

    Run the same blueprint again on an app that already has half of it.

    Reconciliation reuses what matches, updates what drifted, and creates only the remainder. The idempotent rerun is proven on a disposable application, with the receipt kept as evidence.

  4. 04Private Beta

    A workbook becomes schema and data — as two separate steps.

    Upload CSV, XLS, XLSX, or XLSM. Faster Betty profiles the workbook, proposes the mapping, and lets you edit it before anything moves. The schema step and the data step are approved and executed separately, the data step only after publish and runtime permissions are ready, and a paused run resumes from its own token instead of starting over. Errors come back downloadable; the run ends in a receipt.

    Scenario

    Map this supplier workbook onto a new Supplier model.

    You see the detected columns, types, and target properties, adjust the mapping, dry-run the write, then approve the schema. The record write waits for its own approval afterwards.

  5. 05Private Beta

    Record writes go through a gateway you install and own.

    No shared environment token ever writes your data. Record creation runs through an app-scoped custom Action gateway, installed into your application from the Block Store behind its own signed install proposal with a receipt and a rollback line. Batches are app and user bound, count-bounded, exactly approved, and never retried after an unknown provider outcome. Today the gateway covers bounded record creation; update and delete are not implemented.

    Scenario

    Install the record gateway block in this application.

    The server returns the exact signed proposal listing every change. Approving installs it, and the connection card re-polls the gateway status for the honest answer rather than trusting the click.

  6. 06Private Beta

    Runtime writes respect runtime permissions.

    Data API record writes are the only path that touches real data, so they stay behind the published app's own API profile and model permissions. If the profile cannot create the record, the run stops and says so — it does not escalate, and it does not fall back to a builder surface to fake the result.

    Scenario

    Import the approved supplier rows into the published app.

    The data step checks runtime readiness first, writes in bounded batches through the gateway, and reports what landed and what did not.

  7. 07Private Beta

    Your schema as a diagram you can actually move.

    The schema explorer draws the connected application's models, properties, and relations as a read-only ERD. Drag the layout into the shape your head already has, and export it for the design document nobody wanted to draw twice.

    Scenario

    Draw the ERD for this app and export it.

    A navigable graph of the live metadata — no write path, no chance of changing the app by looking at it.

  8. 08Private Beta

    The Betty API, mapped and searchable.

    Faster Betty ships the reference it works from: 347 root operations across the new-builder Meta API's 15 domains, 174 typed My Betty control-plane operations, the Block Store roots, the classic-builder REST inventory, and the Data API runtime surface. It is versioned, served from the product's own database, and searchable while you build.

    Scenario

    Show me the API operation that creates a role.

    The exact operation, its typed arguments and return, the surface it belongs to, and how confident the evidence behind it is.

  9. 09Private Beta

    You sign in on bettyblocks.com. We never see your password.

    Connecting opens an isolated server-side browser and hands you Betty's own sign-in screen. Faster Betty keeps a working builder session and your safe application list, nothing else. There is no browser extension to install, and no password is ever stored.

    Scenario

    Connect the client's application and switch to it.

    You sign in once, get your accessible applications, and pick the one to work in. A session that cannot be captured fails closed and asks you to reconnect — it never silently half-connects.

  10. 10Private Beta

    Every call it makes, in front of you.

    The developer log rail shows the operations the agent ran, which surface they hit, and how they ended, with secret-shaped values redacted. Receipts carry safe fields only. Provider credentials and raw provider responses never enter chat, logs, or receipts.

    Scenario

    Why did that build pause?

    The step that stopped, the surface it was calling, and the reason it refused — readable without opening a terminal.

Not built yet

What is next, labelled honestly.

Everything above is in the Private Beta today. Everything here is not, and says so.

Coming soon

Large migrations

Longer-running dataset moves with progress, recovery, reconciliation, and audit receipts. No volume claim until it is benchmarked.

Planned

Automated Action testing

Repeatable tests across Action paths, permissions, integrations, outputs, and failures.

Planned

Typed writes for pages, components, theming, and integrations

These surfaces are readable today and writable only through an exactly approved operation. Each gets the same inspect, preview, approve, apply, verify contract before it is opened up.

Private Beta access

Point it at your next client app.