actionPilot
ActionPilot is designed for e-commerce businesses and their customers who need fast, reliable support for order tracking, payment status, and delivery changes. Today, customers often face long waiting times, repetitive conversations, and multiple steps to resolve simple requests. Traditional chatbots can answer basic questions but frequently cannot take action, forcing customers to contact human support agents. Businesses, meanwhile, spend valuable time handling repetitive requests that could be automated. ActionPilot addresses this problem with an AI agent that understands customer requests, retrieves relevant order information, and safely executes actions such as delivery rescheduling with explicit user confirmation.
Preliminary score
- Value for the user17.0 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI23.5 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing13.0 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility8.5 / 15
Data requirements, running costs and a clear next step.
- Originality5.0 / 10
A meaningful difference from common solutions.
What the judges wrote
- Claude Opus 5.5Preliminary62/100
- Strengths
- Your agent goes past answering questions: it looks up scoped order, payment and slot data through strict tool schemas and commits delivery reschedules transactionally, with an audit log. The safety design is unusually careful for a hackathon build. It uses a one-use confirmation token behind a UI button rather than a typed 'yes', re-checks capacity and state inside BEGIN IMMEDIATE, and renders replies from validated tool results instead of model claims. You reported a real failure, a cross-customer response leak, and explained how you fixed and retested it, which is exactly the kind of honest testing evidence judges look for.
- To improve
- The track asks for a metric that justifies adoption, but you never name one. Examples would be the share of tickets resolved without a human, time-to-resolution versus a human agent, or cost per resolved request; even rough numbers from your scenarios would help. Your testing would be stronger with numbers: how many pytest cases and scenarios ran, the pass/fail counts, and how many prompt-injection attempts you tried and with what results. Feasibility needs coverage of running cost per conversation on GPT-4o mini, of what integrating a real order system or helpdesk would take, and of a concrete pilot step. As written, it is only 'ticket workflows' in the next-steps line.
- GPT-6 AstraPreliminary72/100
- Strengths
- Your prototype targets a concrete support workflow: checking an order and rescheduling delivery in one conversation. Your documented customer-scoped tools, one-use approval tokens, transactional capacity checks, and atomic audit records provide meaningful safeguards beyond prompting the model. You also describe a cross-customer response failure and its fix, while clearly disclosing the limitations of synthetic data and demo authorization.
- To improve
- Define an adoption metric, such as resolution time or human-agent escalation rate, and compare your workflow with the existing manual controls. Publish reproducible test results, distinguishing live-model scenarios from mocked tests and showing the cross-customer failure before and after the fix. Before a business pilot, bind authenticated accounts to customer identities and roles, restrict Admin access, and make operational order storage persistent. Estimate cost per resolved request and measured latency, including the effect of multiple model rounds.
The team
Javad MustafazadeLead
developer
Amin Mammadov
data
Mahammad Bakhishov
designer