OverwingBook a pilot

Overwing Tower

Clearance for agents on the systems that run the business.

The people who know the green screens are retiring. The agents that could replace the keystrokes get blocked for not identifying themselves, or trusted with writes nobody can audit. Tower sits between them: agents call typed operations, Tower decides whether each write runs on its own, needs a person, or is refused, and signs a receipt for every step.

Book a pilot Open the dashboard

First target: IBM i (AS/400) order entry at mid-market distributors. Ships with a template workflow and a mock adapter you can try today. The screen here is the supervisor’s side: the review queue, and the receipts.

Four principles

Every design choice follows from these.

01

Machine-native

Typed operations with JSON Schema inputs, structured errors that name the field, dry runs, idempotency keys, and a capabilities endpoint. No prose in any agent-facing response.

02

Permissions

Every agent gets its own identity and key, scoped to the operations it may call. Policies gate writes: hard gates, weighted questions, and deterministic checks that never touch a model.

03

Recovery

Idempotent retries return the original result. Every write can declare a compensating operation. Anything uncertain lands in a human review queue with a plain-English summary.

04

Receipts

Every decision, action, review and compensation is a signed link in a per-organization hash chain. An auditor with the public key can verify the whole history offline.

Example

A purchase order arrives by email. What happens next.

The agent reads the PO, looks up the customer, and calls create_order with typed input: lines, total, ship-to, the customer’s credit limit and history.

Fixed rules run first, in code. Required fields present, total under the credit limit. A failure here is a rejection with a structured reason, and no model was involved.

Then the policy asks TypeSafe’s Jev four questions: does this match the customer’s normal pattern, is the ship-to consistent with their history, which intent is this, and how sure are we the lines map to real SKUs. Each answer comes back typed, with a probability and a confidence.

Tower combines them. A confident wrong intent is a hard gate and rejects. Otherwise the weighted score decides: above the auto threshold the order is entered and receipted; in the review band a person sees a plain-English summary and approves or rejects; below the floor it is refused.

If it later turns out wrong, the agent or a person calls compensate, and the defined compensating operation, here cancel_order, runs and is receipted too.

POST /api/v1/tower/actions
Authorization: Bearer ow_agent_…
{ "operation": "create_order",
  "idempotency_key": "po-88213",
  "input": { "customer_id": "C04471", "po_number": "PO-88213",
             "lines": [{ "sku": "FLT-2040", "qty": 24, "unit_price": 12.5 }],
             "total": 300, "source": { "channel": "email", "excerpt": "…" },
             "customer": { "credit_limit": 25000, "avg_order_total": 640 } } }

202 Accepted
{ "action_id": "…", "status": "pending", "review_id": "…",
  "decision": {
    "outcome": "review", "score": 0.71, "provider": "jev",
    "results": [
      { "question_id": "normal_pattern",    "answer": false, "confidence": 0.62, "passed": false },
      { "question_id": "ship_to_consistent","answer": true,  "confidence": 0.91, "passed": true },
      { "question_id": "intent",            "answer": "new_order", "confidence": 0.97, "passed": true },
      { "question_id": "sku_confidence",    "answer": 3,     "confidence": 0.88, "passed": true } ],
    "checks": [ { "check": "credit_limit", "passed": true } ] } }

Design-partner pilot

90 days, one workflow, your real system.

Where Tower is today. The decisions, the review queue and the signed receipts all run. The system on the other end is a mock IBM i. Nothing here has written to a production ERP yet, and a pilot is how the first real adapters get built.

What a pilot is. We pick one workflow with you, order entry or something as contained, and build the adapter that connects it to your system. The adapter runs on your side and connects outbound; Tower never needs a way in. You start in a test environment and move to production when your own team says so.

What we need from you. One person who owns the workflow, access to a test or QA environment, and the three or four operations the agent should be allowed to call.

  • Unlimited
    decisions and dry runs for the 90 days, so the policy can be tuned before anything is written
  • 1,000
    live writes included. If you get near that number we talk before anything is billed, so a pilot cannot produce a surprise bill
  • No fee
    for the first two design partners. In return we ask for a reference we can name, if it works

After the pilot it is $0.25 per executed action, or a fixed monthly commitment with overage at that rate if your finance team needs a number it can plan around.

Apply for a pilot

Pricing

Pay per executed action. Deciding is free.

Separate from the guardrails and Atlas plans. One organization can hold any combination.

$0.25
per executed write action, billed monthly on a Stripe meter
1,000
free decisions and dry runs a month, subscribed or not
0
setup fee. Load the template, create an agent, and try the mock adapter before you pay anything

A real IBM i or SAP system needs an adapter that runs on your side and connects outbound to Tower. That is what the design-partner pilot builds.