VT Labs

Building AI-native business systems & trustworthy agent infrastructure.

Arvanta ERP • LedgerGuard (OSS)
Open source | AI Agents | ERP

[VT Labs @BuildVTlabs]

LedgerGuard v0.2.0, an open source project from VT Labs. it sits between an AI agent and a postgres system of record. the agent can investigate, but a deterministic runtime decides what gets written.

real pnpm demo output below (synthetic data, no db or api keys needed)

[VT Labs @BuildVTlabs]

@ericmacdougall the offset past the one the call got is a clean way to do it. is there a cap on how long you wait before it escalates to a human, or does the permit just sit spent until someone looks?

[VT Labs @BuildVTlabs]

@ericmacdougall the offset past the one the call got is a clean way to do it. is there a cap on how long you wait before it escalates to a human, or does the permit just sit spent until someone looks?

[VT Labs @BuildVTlabs]

@842039796googl the shared credential is the scary half. a spend cap stops the bill, but not an agent with write access posting the same journal entry 40 times in that loop. for finance writes you want per-agent creds plus an idempotency key on every write, so a retry can't land twice.

[VT Labs @BuildVTlabs]

also: approvals bound to the exact persisted action, unclear remote outcomes stay RECOVERY_REQUIRED, and an opt-in experimental odoo 19 adapter. still pre-1.0, tell me what breaks

https://t.co/PyDMdNJABw

[VT Labs @BuildVTlabs]

ledgerguard v0.3.0 is out.

biggest change is for anyone who wants to try it: pnpm demo now pulls ~17mb instead of the whole ~741mb web app, and the column allowlist is configurable, so you can point it at your own postgres table instead of our demo ones

[VT Labs @BuildVTlabs]

@mukitgmbh do write calls get a dry-run or confirm step before they hit the db, or is it the user's access rights plus the audit log? curious how a retried create gets handled if the first response times out

[VT Labs @BuildVTlabs]

@Brendon_Arch yeah binding amount + target is the part that actually matters. once the click is tied to those, anything that drifts after should just hard-fail instead of hoping someone notices

[VT Labs @BuildVTlabs]

@LRosamarina we write the handoff record before anything else: idempotency key, the exact payload, what the read-back saw (or couldn't see), status pending_review. nothing can re-run it until a human marks it landed or not landed, and that call gets logged with who made it

[VT Labs @BuildVTlabs]

@bepituLaz @tanganjojo computer use ke software akuntansi tanpa MCP itu nekat tapi keren 😄 pernah kejadian dia klik "simpan" dua kali atau salah baca angka? kami lagi bikin lapisan approve-before-write buat kasus begini (open source, pre-1.0), penasaran pengalaman mas

[VT Labs @BuildVTlabs]

@kenzoxzero setuju, record rules ngatur siapa yg boleh nulis, bukan apakah isinya masuk akal. kami coba: agen cuma ngusulin, manusia approve rencana persisnya, eksekusi dicek ulang sebelum commit. adapter odoo-nya masih eksperimental: https://t.co/owa6o8qTvk

[VT Labs @BuildVTlabs]

@MSocietyLabs the key also has to be committed in the same transaction as the write. if you only check for it first, two parallel retries can both pass the check.

[VT Labs @BuildVTlabs]

@Brendon_Arch agreed, and the gate is only as good as what the approval is attached to. if it's a yes on a description, the agent can still change the amount or target after someone clicks approve.

[VT Labs @BuildVTlabs]

@ValesyaAI lost reply on a create call is the nasty one. do you key the create on a client supplied id so the retry finds the existing machine, or does it have to list and match afterwards?

[VT Labs @BuildVTlabs]

@ericmacdougall fencing at send makes sense. how do you handle the read of the target when it's lagging, like a replica or a queue that hasn't drained yet? do you treat a stale read as unknown too?

[VT Labs @BuildVTlabs]

at v0.2.0:
- policy: ALLOW, DENY or REQUIRE_APPROVAL
- approval bound to plan id + version
- repairs come from deterministic detectors, not the LLM
- writes are typed corrections, verified before commit, rolled back on mismatch

pre-1.0, postgres only
https://t.co/owa6o8qlFM

[VT Labs @BuildVTlabs]

LedgerGuard v0.2.0, an open source project from VT Labs. it sits between an AI agent and a postgres system of record. the agent can investigate, but a deterministic runtime decides what gets written.

real pnpm demo output below (synthetic data, no db or api keys needed)

[VT Labs @BuildVTlabs]

@0x8bu prod db migrations on a friday afternoon. not because it can't, because it will

[VT Labs @BuildVTlabs]

@sagarmoy22 derive it from the intent not the attempt (plan id + version, not a fresh uuid per retry) and write it in the same txn as the actual write. if a key sits in reserved too long, re-read the target before retrying anything. it's how LedgerGuard does it (oss) if you wanna see code

[VT Labs @BuildVTlabs]

@ericmacdougall +1 on single-use. we also pin the approval to a snapshot of the target state, so if it changed between approve and execute it just refuses. still don't have a clean answer for the timeout where you can't tell if it landed tho. fence at send or on confirmed outcome?