skip to content

we build the systems thatrun the business, decide and act, and can't be wrong

Inscape Labs is a product studio. We build custom software for founders and enterprises and help them decide where AI belongs and where it does not. Our own platform, insights by inscape, keeps that AI's cost, performance and governance visible after handover.

our work

agentic systems

ChaiDEX

Autonomous agents trading across venues, with capital never leaving allocator custody.

non-custodial across CEX, DEX and DeFi
daily NAV reporting

transactional infrastructure

Clove.Trade

A hybrid exchange where speed meets custody: vaults, spot, perps, algorithmic orders and governed agent access.

<2.2ms p99 prototype order placement
~750/sec prototype orders

operational platforms

SirGiving

Discovery, campaigns, rewards and staff workflows, all in one giving platform for donors and nonprofits.

1.2M+ Every.org directory SirGiving integrates with
4 campaign types

1 of 3

ChaiDEX
Clove.Trade
SirGiving

what we do

Three kinds of system, and our own platform for the AI inside them.

Agentic systems, operational platforms and transactional infrastructure — built to run, and instrumented so you can see them running.

  • 01

    Agentic systems

    Process automation and agents that call tools through permissioned interfaces, added only where the workflow earns them. Every action carries a scope, a human approval path and a reviewable record.

  • 02

    Operational platforms

    Workflows, portals, marketplaces and ecosystems. Built around how the operation actually runs, not how the org chart is drawn.

  • 03

    Transactional infrastructure

    Payments, trading, settlement and reconciliation. Built where a bug is a financial loss, not a bug report, so the controls and the reviewable record come first.

  • 04

    insights by inscape

    Our own platform for the cost, performance, evaluation and governance of the AI inside what we build. Available after handover, so the team running the system can see how it behaves.

the operating spine

From the first build to the team that runs it.

  1. Build

    Turn an idea, workflow or operational problem into working software. Shipped in weekly increments the people who will run it can review.

  2. Control

    Define who or what may act, within which limits, with which approvals, and under whose authority. Decided before the build starts, not discovered in production.

  3. Observe

    Make cost, performance, behaviour, exceptions, decisions and outcomes visible. Regressions surface before and after release.

  4. Operate

    Give teams ownership, evidence, alerts and intervention paths after release. The team running the system can answer what happened without coming back to us.

the method

Every build starts where the last one finished.

Each delivery settles questions the next one no longer has to reopen: who may act, who signs off and what counts as working.

What carries over: permissions, approvals, evaluations and records.

contact

Bring one operation.

Name the operation, the decision it turns on and the evidence you need. We come back with:

  • scope
  • a first gate
  • where AI belongs
  • the ownership boundary

email us

hello@inscapelabs.ai

Or let your AI brief us.

Paste this into the tool that already knows your project, then email us what it gives back. It answers what we would ask anyway, so the first conversation starts from facts rather than discovery.

INSCAPE-BRIEF.TXT
You are helping me prepare for a first working session with Inscape Labs, a product studio that builds custom software and the controls around the AI inside it. Use everything you know about my project — this codebase, our chat history, my notes — to answer the questions below. Answer as the project, not as me. Where you do not know something, write "unknown" rather than guessing. 1. THE OPERATION. Which workflow is this about? Who runs it today, with what tools? 2. THE DECISION. What decision does that workflow turn on? Who makes it, on what basis? 3. THE DATA. What does that decision rely on? Where does it live, who can see it? 4. WHEN IT IS WRONG. What happens? Who finds out, how, and how quickly? 5. THE RULES. What approvals or limits already govern it, written or unwritten? 6. TODAY'S STATE. What exists already — spreadsheets, internal tools, vendors, prior AI attempts? 7. THE EVIDENCE. What would you need to see to believe this works? 8. DONE. What does done look like, and by when does it matter? Keep it under 600 words. Be specific and unflattering — that is more useful to them than a pitch.
open inChatGPTClaudeGemini