Avraham Weiss

A local-first platform where fleets of AI agents plan, coordinate, implement, test, and release complex software with limited human oversight. TypeScript/Hono operator API and a React/Tauri desktop app over embedded PostgreSQL.

• Orchestration model for agent fleets, project harnesses, plans, and work queues — collision-safe file claims, dependency-aware scheduling, event-driven wakes, and restart-safe session recovery.
• Blueprint-driven harness system for reusable agent roles and workflows spanning software development, research, review, migration, and general knowledge work.
• Multi-account inference gateway with rate-aware routing and failover, so concurrent agents share model capacity without hard-coding a single provider credential.
• Self-improvement pipelines built on rubrics, scorecards, and feedback loops that turn production observations into prioritized, traceable improvements.
• Release infrastructure spanning unit and integration tests, real Tauri desktop verification, guarded promotion, deploy health checks, and rollback — dogfooded with 50+ concurrent agents on its own codebase.

Three fleets, one desktop

Color-coded agent terminals advancing parallel plan lanes at the same time.

The coordination layer

One agent’s release cut fails on a platform; a peer catches it and unblocks the cut.

The promotion gate

Staging versus main, and the test gate that decides whether anything is allowed to ship.

An automated bidder for prediction markets — Polymarket and Kalshi — built as a Tauri desktop app with an embedded Postgres and a live trading engine. It is strategy-agnostic by design: the same path a backtest replays is the path that trades.

• A real pipeline, not a script. Prospector ingests markets from the venues, an analyst produces a calibrated probability, the engine sizes the position past the risk gate, and the order manager places it — every stage inspectable, every decision auditable.
• Analyst and trader are separated on purpose. The research side emits a calibrated probability and a rationale, and never sizes a position. The money side trades on edge = p_model − p_market, only past a threshold beyond fees and spread.
• Risk is structural. Fractional Kelly sizing, hard exposure caps, idempotent orders, and an armed kill-switch on the top bar of every screen.
• Paper-first, with a pre-registered gate. Real money is not armed until forward-validated evidence clears targets fixed in advance — closing-line value, Brier score, and per-stream scorecards accrued on live market data. The bars do not move to meet the results.

Built on PaperCusp

Oddsmith runs on the same agent infrastructure I built. Its research desk lives in PaperCusp as the oddsmith-ops pot: agents ingest markets from the venues, queue each liquid one as a bet-analysis task, and hand it to an analyst to price into a signal. The trading system’s own development and its daily research loop run on the same coordination, queueing, and audit layer.

The desk

Signal queue, the prospect→forecast→order→position pipeline, and the open book — live on real Polymarket and Kalshi markets.

Pre-registered goals

Every evaluation target is fixed before the data arrives, then scored against real forward results.

“May we arm real money yet?”

One panel whose entire job is to answer that question with evidence instead of confidence.

The company I founded and ran for twelve years: a fully automated commerce platform that generated over $1M per month in revenue while needing only three warehouse staff to operate. Almost none of the difficulty was in the selling — it was in keeping millions of records correct across systems that were never designed to agree with each other.

• Distributed synchronization of inventory, pricing, orders, and listings across millions of SKUs and multiple marketplaces, with serial-level tracking and high-performance caching.
• A fulfillment optimizer that modeled 100K+ SKUs as a weighted graph; bitmap indexing evaluated millions of configuration paths and recomputed lowest-cost fulfillment in roughly sixty seconds.
• An LLM-assisted product matcher that combined model confidence with human-calibrated thresholds, so high-confidence marketplace matches could be automated safely and the rest escalated to a person.
• Microservices for distributed execution and cross-machine communication, plus automated listing, advertising, price-history, and availability engines.

A demonstration build, not a business — a multi-marketplace listing platform and B2B storefront I put together to show the architecture end to end. The catalogue and the figures on it are sample data; there are no real customers or orders behind it.

• One description in, six marketplaces out. A universal product schema is the pivot; per-marketplace adapters map it to Amazon, eBay, Walmart, Backmarket, Newegg, and Google Shopping.
• The model sits inside the typed path, not around it. An LLM classifies the product type, then extracts properties under the matching Zod schema — validated and rejected on a miss, never quietly defaulted.
• Vision-verified imagery. Candidate product images are checked by a multimodal model — no watermark, single product, actually matches the description — and the listing is rejected if none pass.
• NestJS microservices over a Redis transport with Postgres and Drizzle, each marketplace subscribing to its own listing topic, plus a description cache keyed by content hash so repeat inputs skip the model entirely.

The storefront

The demo front end the listing platform publishes into — sample catalogue, real pipeline.

description
  ↓ classify · extract · validate
universal product
  ↓ verify imagery
  ↓ map per marketplace
amazon · ebay · walmart
backmarket · newegg · google

The listing flow

One typed pivot in the middle, so a new marketplace is an adapter rather than a rewrite.