AI / Agentic Systems · Business Operations
DealFlow: Building an AI Operating System for Marketplace Resale
DealFlow is an AI-assisted operating system I built for a used-phone resale business. It connects marketplace sourcing, device evidence, pricing, seller conversations, inventory, and resale outcomes. Vassa is the conversational assistant; code controls the financial limits and the actions it is allowed to take.
The problem: a cheap listing is only the start
Used-phone resale connects a lot of small decisions: find a real listing, identify the exact device, understand its condition and lock status, estimate a realistic resale value, negotiate within a margin, and carry the deal through inspection and sale. Getting one of those wrong can erase the profit.
I wanted an operating system that could carry the evidence and economics through the whole workflow. A persuasive message or a promising asking price is not enough to make a deal worth doing.
My role
I designed the workflow, pricing rules, approval boundaries, and operator experience, and used AI-assisted development to implement, debug, test, and refine the system. That work spans Python services, database models and migrations, marketplace integrations, conversational AI, a dashboard, and operational checks.
The business context drives the technical decisions: what needs to be known before an offer, what a deal can afford, where an automated conversation should stop, and what information the owner needs to take over.
What I built
- Marketplace discovery, listing-detail capture, and catalog matching
- Photo assessment and provider-backed device-identity checks
- Versioned evidence, conflicts, and source-freshness checks
- Deterministic resale-route valuation, costs, profit requirements, and buy ceilings
- Stateful seller conversations and bounded offer / counter-offer workflows
- Exact-message approvals and action-time revalidation
- Capability controls for observation, questions, outreach, and negotiation
- Inventory, cost-basis, sale, and realized-outcome records
- Vassa web workspace with saved chats, streaming, deal context, and usage visibility
- Bounded MCP tools, immutable action proposals, and an execution audit trail
How a deal moves through the system
Listing text and photos become evidence for an assessment. Pricing uses that assessment and versioned market sources to establish the available resale routes and a buy ceiling. The conversation layer works inside those limits; the action layer checks whether the next step is permitted.
The diagram connects the implemented components. The documented automatic negotiation path stops at an owner handoff before meeting setup, purchase, or payment.
- Marketplace listings
- Identity / condition evidence
- Resale value / buy ceiling
- Permitted next action
- Bounded negotiation
- Owner handoff
- Inventory / resale records
- Outcomes / corrections
Evidence and money stay outside the model
Device model, storage, condition, carrier status, and identity need supporting evidence. The system separates observations from assessments, records conflicts, and can hold a candidate when information is missing or contradictory.
Price calculations use deterministic decimal arithmetic, source references, route costs, profit requirements, and rounded buy ceilings. Updated device facts or expired source data can invalidate a price and its unsent draft. The model cannot make a deal acceptable by sounding confident about it.
Vassa: a conversational interface with a defined scope
Vassa brings the operating context into a persistent workspace with saved chats, streaming responses, deal scope, source links, and visible usage. Its bounded tool interface can read the overview, deals, a selected deal, inventory, and metrics, or prepare an action for review.
Preparing an action does not execute it. An approval refers to an exact, immutable proposal. Before execution, the system rechecks the current draft, relevant facts, price ceiling, and permissions. A changed or expired proposal needs fresh review; an ambiguous send outcome is held for reconciliation instead of being blindly retried.
Process, QA, and controlled rollout
I separated observing, assessing, asking questions, making offers, negotiating, and purchasing into distinct capabilities. Shadow decisions and evidence records allow a proposed action to be inspected before a capability is enabled for a particular workflow.
The repository includes regression coverage for pricing and source freshness, evidence conflicts, changed assessments, exact-message approvals, duplicate execution, provider checks, and the owner handoff. The Vassa workspace also has contract, runtime, storage, route, and tool-boundary tests.
One regression checks that enabling outreach and negotiation leaves meeting and purchase authority disabled. That is a concrete example of the operating boundary being enforced in code.
What has been demonstrated, and what remains
The documented live workflow reached evidence-backed opening offers and bounded negotiation up to an owner handoff. Meeting setup, purchase, and payment remained outside that autonomous scope. The later Vassa web workspace was built and tested; its production deployment is not yet verified. The expanded end-to-end purchase and resale workflow remains unfinished.
Tools and working methods
- Python
- FastAPI
- PostgreSQL / Supabase
- Pydantic
- Playwright
- Vision / LLM APIs
- Telegram
- Hermes / MCP
Result
DealFlow connects sourcing, evidence, pricing, seller conversations, and operating records, with documented live validation of a bounded negotiation workflow. The Vassa web workspace adds a tested conversational interface to that foundation. The result is a system that can carry a candidate from discovery to an evidence-backed offer and a clear owner handoff.
What I learned
Useful autonomy comes from deciding exactly what the system is allowed to know, recommend, and do. The hard work is carrying reliable facts, money limits, and state across the whole process, then making the handoff clear when a human needs to take over.