Vlaander
← All engines

AGT · Commerce Infrastructure — Agent-Operated Sales Desk

VLA-Agent — Telegram Sales Chatbot

Source code for a Telegram sales chatbot: an AI agent that sells digital products, designed so the language model is an untrusted clerk and prices, inventory, signatures and money are meant to sit where the model cannot write. Pre-production, with four open high-severity review findings.

Maturity. Pre-production. Vlaander has not run the test suite. The shipped docker-compose.yml connects every process, including the Telegram model host, as the PostgreSQL superuser with a default password of "vla", so the per-role controls described below do not apply as shipped. Vlaander's internal review on 7 October 2026 confirmed four high-severity findings in the code, none fixed. The unattended close (on-chain payment watching and automated delivery) is not part of the shipped deployment, and the counsel-approved contract templates, screening vendor, custodian provisioning and key ceremony are still outstanding.

Overview

VLA-Agent is the system Vlaander built to sell its own source-code assets through a chat agent. A buyer talks to the agent on Telegram, and the model (Anthropic's API) can act only through a gateway of seven tools: five that read and two that insert rows (opening a deal and joining a waiting list). The repository's design goal is that an attacker who owned the model host could not change a price, double-sell a lot, apply a signature, release source or move funds. As shipped, that goal is not met: the host process runs as the database superuser, and the review found that a payment instruction is issued before signature or reservation.

The source has twelve services. TypeScript: a price book and inventory ledger, a decision engine for screening and use-code rules, a hash-chained append-only record store with a kill switch and incident register, a treasury, contract compilation from approved templates, the agent host, go-live tooling, an origination perimeter and an end-to-end test package. Rust: a delivery-versus-payment worker and a second signing identity.

The code requires two identities for the delegated signature: a TypeScript service and a separate Rust binary that re-reads the deal with different SQL under its own database role and must compute the same digest. That separation exists only in the test harness's database roles; the shipped compose file gives every process the same superuser connection.

The problem

Selling software through an AI agent carries a risk: a model can be talked into a discount, a second sale of an exclusive asset, a changed payout address or an early release of the source. VLA-Agent's approach is to give the model only enquiry tools and to put prices, inventory, signing and payment in a control plane the model has no tool to write. A buyer should read this as a design with working code behind much of it, not as a hardened deployment.

What it does

  • Versioned price book with a database CHECK requiring two different approvers; price entries have no UPDATE grant, and the gateway refuses to serve when its deploy pin no longer matches the current Price Book.
  • Inventory ledger where exclusivity is a partial unique index allowing one blocking lot per SKU; a lot is reserved by one conditional insert, idempotent on the deal.
  • Decision engine: screening results with mandatory list versions, policy rules as data with clause citations, a closed use-code gate, sender re-screening and a review queue. No screening vendor is wired in.
  • Append-only, hash-chained record store with a seven-year retention floor enforced by a CHECK constraint, a per-deal reconstruction command, a kill switch and an incident register with sixteen incident kinds.
  • Treasury: a sweep allowlist limited by CHECK to three destination kinds (payoff, refund reserve, quarantine), reserve maths and inbound-payment classification. The shipped flow uses one published receiving address for every deal, not a wallet per deal.
  • Delivery versus payment in Rust: chain watcher, a nine-predicate tick, a transactional outbox and pre-encrypted delivery. It needs a chain source and a delivery service, so it is not in the shipped compose file.
  • Contract compilation from approved templates only, with single-pass substitution. The only template shipped is a draft, so the contract rail can sign nothing until counsel approves one.

Performance

No benchmark figures

AGT publishes no benchmark figure, so its value rests on the assurance and scope below rather than on a number to reproduce.

Value in your own metrics

Forbidden-tool build check
The build fails if any of 21 forbidden tools, such as setting a price, marking a deal paid or releasing source, is defined in service source. Vlaander ran the check on 8 October 2026 on the delivered archive (Node 24, Codespace): 106 source files scanned, 0 definitions.
Double sale of an exclusive lot
Refused by the database: a partial unique index allows one blocking lot per SKU. The review found that payment instructions are sent before a lot is reserved, so several buyers can still be told to pay for the same lot.
Payout destinations
Sweeps can go only to the three destination kinds allowed by a CHECK constraint. Nothing in the code can send funds; custody is watch-only.
Record retention
Each record must be kept at least seven years from when it was recorded, enforced by a CHECK constraint, and a command rebuilds the record of one deal.

Assurance and build

Languages
TypeScript (Node 22 or later; the Docker image uses Node 24) and Rust (2021 edition), on PostgreSQL 16
Size
12 services; about 27,000 lines of source, SQL migrations and scripts, and about 18,700 lines in 102 test files; 711 TypeScript and 133 Rust test functions declared (counted by Vlaander in the delivered archive, 8 October 2026; not run)
Internal review
Vlaander quality review, 7 October 2026: 0 critical and 4 high findings, all confirmed in the code and open. (1) The shipped docker-compose.yml runs every service as the PostgreSQL superuser with default password "vla". (2) The output filter catches only 0x addresses, so the bot can be made to post a false payment destination. (3) A payment address and amount are given on a GREEN screening, before signature or reservation, contrary to the system card and README. (4) The gateway's database role can insert GREEN decisions and operator records. Five medium and nine low findings were reported but not confirmed by the reviewer. The review found every SQL query parameterised.
Internal audits
Two control audits written during development and shipped with the source: VLA-AUD-001 (sixteen findings) and VLA-AUD-002 (three critical, nine high and two medium findings; nine closed, two accepted and three partly fixed by its own account). The gateway's ability to forge a GREEN decision is one of the open items. No external penetration test.
Test suite
Not run by Vlaander; it needs PostgreSQL 16 and the Rust toolchain
Repository
Vlaander-LTD/VLA-Agent, branch vla-agent-control-plane, commit 6c94151

Releases are not yet cryptographically signed, and no release manifests or external audit summaries are published. Check the source tarball you receive against its SHA-256 in Schedule 1 of your Sale and Assignment Agreement, which you see before you sign.

Scope and maturity

What is real today, what is deliberately excluded, and what is pending — published unprompted.

Included today

  • The twelve services as source, with their tests, SQL migrations, Dockerfile, docker-compose.yml, CI workflow and deployment scripts.
  • The scope of work, architecture record, deployment and go-live runbooks, drafting briefs for counsel and both internal control audits, plus a handover note listing the Vlaander identifiers that were replaced with placeholders.

Explicitly scoped out

  • Vlaander's own operation of the desk. Vlaander stops using it on sale.
  • Vendors it is designed to plug into but has not contracted: screening, e-signature, custodian provisioning, a chain source and an FX source.

Pending

  • Fixes for the four open high findings: per-service database roles in the deployment, payment destinations kept out of model text, no payment instruction before signature and reservation, and no gateway write access to decisions or operator records.
  • Counsel-approved sale and assignment templates; until then the contract rail runs and can sign nothing.
  • A chain source and delivery service for the Rust closing loop, an external red team and penetration test, and the witnessed key ceremony.

Who it's for

  • Software and IP vendors that want to sell through a chat agent without giving the model authority over price, inventory or money.
  • Digital-asset and stablecoin businesses interested in delivery-versus-payment release of a digital good against an on-chain payment.
  • Agent-platform companies looking for a worked example of keeping an LLM out of the control path, with its gaps documented.

Before you buy

  1. Plan to run the full test suite yourself after delivery (PostgreSQL 16, Node 22 or later and Rust required); Vlaander has not run it, and the source is released only after payment.
  2. Check the four open high findings listed above against docker-compose.yml, services/vla-gateway/src/tools.ts, services/vla-host/src/claims.ts and the gateway migrations.
  3. Read both internal audits and the go-live runbook; `pnpm readiness` lists what still blocks go-live.
  4. Budget for replacing Vlaander's catalogue, price book, policies and Board constants with your own; the desk ships configured for Vlaander's assets.
  5. No refund is available after delivery, except where a remedy cannot lawfully be excluded.

What transfers

  • The asset's sourceSubject to the Sale and Assignment Agreement, Vlaander assigns to the verified Buyer the transferable right, title and interest that Vlaander owns in the specified Asset. The assignment excludes Third Party Materials, open-source components, Vlaander’s pre-existing tools, generic know-how, development methods, trademarks, confidential information and any rights that cannot lawfully be assigned.
  • Its testsThe test suite the published assurance claims rest on, as delivered in the source archive.
  • Its audit artefactsSpecifications, model-checking output, reviews and the software bill of materials, where the asset has them.
  • Not includedThird-party and open-source materials are not sold or assigned by Vlaander. They remain under their own licences, listed in each asset’s software bill of materials (SBOM.md in the archive), and the Buyer is responsible for complying with those licences.

Sale and ownership terms → Sale and Assignment Agreement →

First described in: Vlaander, 5 October 2026 (added after the VLA-GEN catalogue). Revised by Vlaander against the delivered source; every figure is labelled with its basis.

From test to source

  1. 01

    Check

    Read the engine's page: what Vlaander measured and on which hardware, what it has not measured, and the open review findings. Nothing runs before purchase.

  2. 02

    Buy

    Verified businesses only. Place the order, give your company's details, have your authorised signatory sign the Sale and Assignment Agreement, then pay the invoice in naira by bank transfer, or in USDC on Polygon. Once the payment is verified, your account shows Paid.

  3. 03

    Receive

    We confirm the funds and release the source tarball to you. Delivering, then Download ready. Check it against the SHA-256 in Schedule 1, then rerun the tests and benchmarks yourself.