Build and deploy a human-supervised eBay buying agent that will discover listings daily, analyzes listing data and images, produces an explainable buy-score, requests approval by Twilio SMS, and permits only bounded, explicitly authorized transaction actions.
This Lab is currently educational and does not execute code or external actions.
Difficulty
Advanced
Estimated time
8 hours
Cost band
Moderate
Length
17 Steps
Business outcome
Deploy a human-supervised buying agent that continuously discovers relevant eBay listings, prioritizes strong purchasing opportunities, and reduces the time required to evaluate and act on listings.
Configured eBay searches execute automatically once per day
Every qualifying listing receives a structured 0-100 buy-score with supporting rationale
High-value candidates are delivered by SMS with a direct listing link and bounded recommendation
No offer, bid, or purchase occurs without explicit human authorization
Define what the agent should look for, how opportunities are evaluated, and what it is never allowed to do without human approval.
Instructions
Choose a realistic eBay search target and define the maximum price, desired condition, required listing evidence, seller requirements, and deal-breakers.
For this Lab, use "Paper Mario Nintendo 64 CIB" as the worked example.
The agent may discover, analyze, score, and recommend listings. It must not submit an offer, bid, or purchase based only on its own recommendation.
Define both a maximum acceptable item price and a maximum acceptable total transaction charge. The total charge should account for known shipping and any other amounts available before execution.
Worked example: search for Paper Mario Nintendo 64 CIB. Prefer authentic complete-in-box copies with cartridge, box, and manual visible. Evaluate price, completeness, seller reputation, listing evidence, shipping, returns, and collection fit. Discovery and scoring are autonomous; financial actions require explicit human approval.
Lab Step 2of 17
Learn
Map the eBay buying agent
Separate discovery, agent reasoning, approval, and financial execution into clear system boundaries.
Instructions
Trace the workflow from the daily scheduler through eBay discovery, listing normalization, agent scoring, Twilio notification, human approval, and the bounded eBay action adapter.
Identify which components may read external data and which components may cause external changes.
Add instructional content.
Lab Step 3of 17
Agent
Define the bounded buying agent
Define what the agent may reason about and recommend without granting it financial execution authority.
Execution unavailable in Studio 0.0.2. This Lab Step is structured educational content only.
Instructions
Review the agent responsibility, inputs, outputs, capabilities, and non-negotiable operating boundaries before using Codex to implement it.
The model may evaluate listings and propose actions. Deterministic application logic and explicit human authorization control all consequential actions.
Evaluate normalized eBay listings, produce evidence-based scores and recommendations, and propose next actions within deterministic policy boundaries.
Inputs
Normalized listing metadata
Listing image evidence
Configured buying policy
Historical candidate state
Outputs
Structured buy-score
Sub-scores with supporting evidence
Risks and missing information
Confidence assessment
Recommended action
Proposed offer and recommended ceiling
Tools / capabilities
Analyze listing text
Analyze approved image evidence
Compare observed listing attributes with buying policy
Produce structured recommendations
Operational boundaries
Cannot approve its own financial action
Cannot exceed a human-approved maximum
Cannot treat missing evidence as confirmed fact
Cannot call production eBay financial-write APIs unless separately enabled and authorized
Lab Step 4of 17
Test
Verify Codex on the VPS
Confirm that the prerequisite Codex development environment is available before building the agent.
Instructions
Complete the prerequisite "Codex on a DownDoggy VPS" Lab first.
Then verify that you can SSH to the VPS as the approved non-root operator, enter the project workspace, run Codex, access Git, and run a basic project test without exposing credentials.
Validation mode
Manual
Expected result
The developer can safely use Codex against the project repository from the VPS.
Validation instructions
Connect to the VPS, verify the operator identity, enter the project directory, start Codex, and confirm Git repository access.
Regression criteria
Do not use root for normal development
Do not paste API secrets into Codex prompts
Do not continue if Git or VPS identity is unexpected
Lab Step 5of 17
Prompt
Have Codex scaffold the buying agent
Use Codex to create the deterministic application structure around the future scoring agent.
Instructions
Copy the prompt into Codex from the project directory on the VPS.
Review Codex's implementation plan before accepting code changes.
Scaffold a human-supervised eBay buying agent.
Edits stay in this browser.
Lab Step 6of 17
Security Stop
Configure eBay access safely
Establish eBay credentials and distinguish read access from purchasing authority.
Instructions
Create or select the eBay developer application and begin with Sandbox credentials.
Store credentials in the VPS secret/environment configuration, never in source files or Lab content.
Confirm what APIs the application is actually permitted to use before enabling any eBay write capability.
!
Stop and reviewSecurity Stop
Pause and understand the boundary before continuing.
Data visible
Public eBay listing metadata
Listing images
Seller metadata
OAuth account identity and authorization scope
Read capabilities
Search eBay listings
Retrieve listing details
Retrieve listing image URLs
Read seller and buying-option metadata
Write capabilities
No production financial write capability is enabled during this step
Sandbox or mock transaction capability may be enabled only after validation
Credential types
ebay-client-id
ebay-client-secret
ebay-user-oauth-token
Affected systems
eBay Developer Platform
eBay Sandbox
eBay production marketplace
Logging considerations
Never log eBay client secrets, refresh tokens, or access tokens
Redact OAuth authorization headers
Record item IDs and action outcomes without recording credential values
Emergency stop / rollback
Keep all eBay financial write actions disabled. Set PURCHASES_ENABLED=false and DRY_RUN=true. Revoke or rotate application credentials if credential exposure is suspected.
Risk notes
Read-only discovery and financial write access are separate trust boundaries
Production purchasing APIs may require eBay approval or additional entitlement
OAuth scopes must be limited to the minimum required capability
The Lab must not assume that production purchasing access is available
Human approval required: Yes
Lab Step 7of 17
Test
Discover real eBay listings
Run a read-only search against eBay and normalize real listing data.
Instructions
Search eBay for:
Paper Mario Nintendo 64 CIB
Retrieve several candidates and normalize each into the application's ListingCandidate representation.
Capture the eBay item ID, title, item URL, price, shipping, condition, seller information, buying options, and available image URLs.
Do not perform an offer, bid, or purchase.
Validation mode
Deterministic
Expected result
Real eBay listings are normalized and stored without performing any write operation.
Validation instructions
Execute one read-only discovery cycle for the configured example search and inspect the normalized candidates.
Regression criteria
Duplicate item IDs do not create duplicate candidates
Malformed listings fail safely
No offer, bid, or checkout endpoint is called
Lab Step 8of 17
Prompt
Build the listing scoring agent
Build the listing scoring agent
Instructions
Implement an explainable scoring agent for ListingCandidate.
Return structured JSON containing:
overall_score: 0-100
subscores:
- value: 0-35
- condition_and_completeness: 0-20
- seller_confidence: 0-15
- listing_evidence: 0-10
- shipping_and_returns: 0-10
- target_fit: 0-10
Also return:
- rationale
- risks
- missing_information
- confidence
- recommended_action
- proposed_offer
- maximum_recommended_price
The application, not the model, must enforce the valid numeric ranges.
The model must never execute an offer or purchase.
Use Codex to implement an explainable, policy-bounded agent that evaluates normalized eBay listings and produces structured purchasing recommendations without receiving authority to perform a financial action.
Edits stay in this browser.
Lab Step 9of 17
Test
Validate the scoring agent
Verify that scoring is structured, explainable, bounded, and sensitive to missing evidence.
Instructions
Run the Paper Mario fixture through the scoring system and inspect the structured result.
Then remove evidence that the manual is present and run the fixture again.
The second evaluation should reduce completeness or confidence rather than inventing the missing manual.
Validation mode
Deterministic
Expected result
The normal fixture is treated as a strong candidate, while removal of completeness evidence lowers confidence or the relevant assessment without inventing information.
Validation instructions
Run the scoring fixture and its missing-evidence variant through the automated scoring tests and inspect the resulting structured output.
Regression criteria
Scores outside configured ranges are rejected
Malformed model output is rejected
Missing evidence is not hallucinated
The agent cannot turn a recommendation into financial authorization
Lab Step 10of 17
Security Stop
Protect the SMS approval boundary
Treat an SMS reply as financial authorization only after authenticating it and binding it to one exact candidate.
Instructions
Configure Twilio credentials outside Git and review the inbound webhook boundary before accepting approval messages.
Approvals must come from the configured operator number, pass Twilio request validation, identify a one-time candidate ID, specify the approved ceiling, and expire.
!
Stop and reviewSecurity Stop
Pause and understand the boundary before continuing.
Data visible
Operator phone number
Candidate ID
Approval command
Maximum authorized amount
Twilio request metadata
Read capabilities
Read the candidate awaiting approval
Read configured operator identity
Write capabilities
Record an authenticated approval or rejection
Advance one candidate to an approved state
Credential types
twilio-account-sid
twilio-auth-token
Affected systems
Twilio Programmable Messaging
Logging considerations
Do not log the Twilio Auth Token
Redact phone numbers where the full value is unnecessary
Log approval IDs and state transitions rather than unnecessary message content
Emergency stop / rollback
Disable the inbound approval route or messaging integration and keep the financial action adapter disabled until webhook authenticity and state are verified.
Risk notes
A forged SMS request must not become authorization
A generic yes response is insufficient financial authorization
Replayed approval messages must be idempotent
Human approval required: Yes
Lab Step 11of 17
Prompt
Build the Twilio approval workflow
Build the Twilio approval workflow
Instructions
Build the Twilio approval workflow
Use Codex to implement outbound candidate alerts and authenticated, bounded inbound SMS approval.
Edits stay in this browser.
Lab Step 12of 17
Human Approval
Authorize one bounded transaction
Authorize one bounded transaction
Instructions
Authorize one bounded transaction
Proposed action
Authorize the agent workflow to proceed with one bounded transaction for the selected eBay listing.
Why approval matters: An offer, bid, negotiation, or purchase can create an external financial obligation.
Consequences
Approval applies only to the identified listing and quantity
The approved monetary ceiling may not be exceeded
A changed or higher required amount requires new approval
Rejection prevents the candidate from reaching financial execution
If approved
The candidate may advance to bounded transaction handling.
If rejected
The candidate is skipped or closed without financial action.
Lab Step 13of 17
Test
Test the bounded negotiation logic
Test the bounded negotiation logic
Instructions
Use the mock eBay action adapter.
Simulate an opening offer of $105 with a human-approved maximum of $115.
Test a seller counteroffer of $112 and then a separate counteroffer of $119.
Validation mode
Deterministic
Expected result
The $112 scenario may continue within the existing authorization. The $119 scenario stops and returns to human approval.
Validation instructions
Using the mock transaction adapter, simulate an opening offer of $105 with an approved ceiling of $115. Test one seller counter at $112 and another at $119.
Regression criteria
The authorized maximum cannot be changed by the agent
A counter above the approved ceiling cannot execute
Mock negotiation does not call a production eBay write interface
Lab Step 14of 17
Test
Prevent duplicate financial actions
Prevent duplicate financial actions
Instructions
Prevent duplicate financial actions
Validation mode
Deterministic
Expected result
The system records and executes at most one bounded transaction attempt for a valid authorization and rejects every stale, duplicate, changed, or already-consumed path.
Validation instructions
Submit the same approval multiple times, replay the webhook, test an expired approval, change the listing price above the approved ceiling, and simulate an already-completed transaction.
A listing above the approved ceiling cannot execute
A completed authorization cannot be reused
Lab Step 15of 17
Deploy
Deploy the buying agent to the VPS
Deploy the buying agent to the VPS
Execution unavailable in Studio 0.0.2. This Lab Step is structured educational content only.
Instructions
Deploy the buying agent to the VPS
Target:downdoggy-vps
Deploy the reviewed application to the DownDoggy VPS as supervised application and scheduled-worker processes. Configure secrets outside source control, persist workflow state, expose only the required authenticated HTTPS webhook, and keep DRY_RUN=true and PURCHASES_ENABLED=false during Lab acceptance testing.
Prerequisites
The application test suite passes
The DownDoggy VPS prerequisite Lab is complete
The eBay read-only integration works
Twilio webhook validation works
Persistent state is configured
A rollback path is available
Rollback
Stop the application and scheduler, leave persistent state intact, disable the Twilio route if necessary, and keep all eBay financial-write capability disabled while restoring the previously reviewed application version.
Lab Step 16of 17
Test
Run the complete buying-agent acceptance test
Run the complete buying-agent acceptance test
Instructions
Run one forced discovery cycle against real read-only eBay data.
Allow one qualifying candidate to be scored and sent through the real Twilio integration.
Reply with a valid bounded approval.
Complete the resulting transaction through the mock or permitted Sandbox adapter only.
Validation mode
Manual
Expected result
One candidate travels from discovery through scoring, recommendation, authenticated human approval, and exactly one bounded mock or Sandbox transaction while preserving an auditable state history.
Validation instructions
Run one forced discovery cycle, select one real read-only eBay candidate, allow the scoring and policy workflow to generate a recommendation, receive the real SMS, return a valid approval, and complete the action using only the configured mock or Sandbox transaction adapter.
Regression criteria
No production financial action occurs
No unauthenticated SMS creates approval
No action exceeds the authorized ceiling
No duplicate event creates a duplicate transaction
A failed step remains visible and recoverable
Lab Step 17of 17
Observe · Optional
Observe the daily agent
Observe the daily agent
Instructions
Observe the daily agent
Review the signals after the forced acceptance cycle and again after the first scheduled cycle. Investigate repeated provider failures, unexpected state transitions, rising per-candidate cost, or any attempted action outside the configured authority boundary.
