Asap

• 

  Asap

Inspiration

The idea for ASAP came from watching how fragmented everyday services have become. There are dozens of apps and websites offering different services, and every time people want to get something done, they have to learn a new app, understand a different interface, and figure out the process all over again.

But people don't want to learn how every platform works. They just want to get things done.

We wanted to build something different: an agent that understands what a person wants and handles the task for them, instead of an app they have to operate. The pattern that makes that work isn't the integrations, it's the restraint: the agent doesn't narrate what it's about to do, doesn't ask "should I proceed?" for something the user already told it to do, and doesn't hand back a wall of options when one clear action is obvious. It just does the thing, and only interrupts when there's a real decision on the table.

When we saw the Everyday Agents track, that was the exact shape of problem it's asking for, something people actually deal with, handled end to end, not just chatted about. So for this submission we took the one part of ASAP's own purchase logic that's genuinely reusable in isolation, the VTpass integration and its crash-safety rules, and rebuilt it as a small, standalone Strands agent, with the "runs quietly" behavior written directly into the system prompt as an explicit, auditable rule instead of scattered across code.

What it does

ASAP is an AI agent that helps people complete everyday tasks on their behalf: booking rides, flights, and hotels, ordering food and products, buying airtime and data, paying bills and subscriptions, and more. For example:

"Book me a Bolt from Lekki to the airport."

ASAP understands the request, collects whatever information it needs, finds available options, shows the user the relevant details and price, and asks for confirmation before completing the transaction. It's available through WhatsApp, Telegram, and MCP, so it can be reached directly or through AI platforms like ChatGPT and Claude.

This submission narrows that down to one concrete, fully working slice built specifically for the hackathon: airtime top-ups over Telegram, on the Strands Agents SDK. Message the bot: "send 500 naira MTN airtime to 08012345678." If the network, number, and amount are clear and the wallet can cover it, the airtime is bought immediately, no confirmation step, no menu, no app to open. If the wallet's short, it says so and states the exact shortfall instead of guessing. If something's ambiguous, it asks exactly one question, never a form.

It's a real integration, not a mock. Purchases go through VTpass, a real Nigerian billing aggregator, with its full response-code handling ported faithfully, including the trap where VTpass's 000 response code means "accepted," not "delivered."

How we built it

We built ASAP as an agentic layer that connects natural-language instructions to real-world services: the agent interprets what the user wants, asks for missing information, connects to the relevant service, presents the available options, and executes the task after the user's explicit confirmation. We built integrations with services like Bolt for ride booking, plus infrastructure for airtime, bills, and subscriptions, and a merchant layer that lets local businesses list their products and become reachable through ASAP without building their own agent.

For this submission, the airtime flow above runs on two tools, one system prompt, and Strands' own agent loop doing the rest:

• check_wallet_balance reads a demo wallet (SQLite, kobo-denominated to avoid float drift on money), seeded fresh for every new chat.
• buy_airtime debits the wallet first, then calls VTpass, keyed by a deterministic reference so a retried tool call can't double-debit. If VTpass's own response proves nothing was actually charged, the debit reverses. If it doesn't prove that, the debit stays in place for review, never guessed at either way, the same crash-safety rule the production system enforces.
• The system prompt encodes one autonomy rule in plain language: act immediately when the facts are clear and funded, ask exactly one question when they're not, never ask permission for something already asked for.

Strands' model-agnostic design ended up mattering more than expected (more on that below), and python-telegram-bot handles the chat interface, one agent instance kept per chat so conversations don't bleed into each other.

Challenges we ran into

One of our biggest challenges was realizing how dependent an AI agent can be on third-party platforms. Within the first two weeks of our initial MVP launch, our WhatsApp Business account was permanently suspended without any clear explanation. We appealed, but the suspension remained. That showed us the risk of building our entire distribution around a platform we don't control, and pushed us to treat WhatsApp, Telegram, and other platforms as channels rather than as the foundation of ASAP, which is part of why this submission is built channel-agnostic on Telegram through Strands rather than tied to any one platform.

Another major challenge has been merchant onboarding. In Nigeria and across Africa, many everyday transactions happen through local vendors with no APIs or digital infrastructure. Getting these businesses onto ASAP, collecting their products and pricing, and making them accessible to an AI agent has been a slow, manual process.

On the technical side of this specific submission, we hit a few sharper problems:

Bedrock access was the first wall, not the model. The IAM user set up for this started with no bedrock:* permissions attached at all, so every run failed with an access-denied error before it ever reached a model. We tracked that down and attached the missing policy, which cleared the permissions gap, but waiting on that fix (and on model access being enabled for the account) still would have stalled the build. Rather than block on an AWS console round trip, we leaned on the thing Strands actually advertises: bring any model, swap freely. _build_model() now picks Anthropic directly when ANTHROPIC_API_KEY is set, and falls back to Bedrock otherwise. Bedrock does reach the model correctly now (we confirmed this mid-build by running into its own daily token throttling limit, which only happens after authorization succeeds), but the agent no longer depends on that specific path being available.

A raw Python object almost shipped straight to a real user. Once the model calls were working, the bot's replies looked like this in Telegram:

{'role': 'assistant', 'content': [{'text': "Hey! I can help..."}], 'metadata': {...}}

AgentResult already has a __str__ that extracts just the text blocks out of result.message and joins them cleanly. The bug was one attribute off: stringifying result.message (the bare dict) instead of result (the object with that extraction logic already built in), an easy mistake to make and an easy one to miss if you're only glancing at whether a reply came back, not what was actually in it.

The agent could have answered from memory instead of from the ledger. Strands keeps a chat's conversation history in process, which is exactly what gives it memory across turns, but it also means nothing stops the model from reusing a balance figure it already stated a few messages ago instead of checking again. The purchase path itself was never actually at risk (the wallet store checks the real, current balance on every debit regardless of what the model believes), but what the model said to the user could go stale the moment a purchase changed it. Fixed by saying so explicitly, twice: once in the system prompt, once in the tool's own docstring, since tool descriptions carry more weight for tool-choice behavior than prompt text alone.

Sandbox realism. VTpass's sandbox doesn't deliver anything, it reads the phone number sent to it as an instruction for which canned response to return. Worth documenting loudly, because a real phone number typed out of habit hits the sandbox's generic failure branch and reads as a bug in the integration rather than the sandbox behaving exactly as designed.

Accomplishments that we're proud of

We're proud that we moved ASAP beyond an AI demo into a system capable of interacting with real-world services. We secured access to Bolt's Ride Booker API and built the integration for booking rides through ASAP, onboarded our first local vendors, and built infrastructure for them to receive orders through the platform. ASAP is already reachable through WhatsApp, Telegram, and MCP, and this submission adds a fully working, real-integration proof that the same money-safety design travels cleanly onto a different SDK and a different model provider without changing its behavior.

Most importantly, we've started validating the core idea with real users: people can say what they want in plain language and have an agent handle the complexity.

What we learned

We learned that building an AI agent is only one part of the problem. The harder part is connecting the agent to the real world through reliable services, payments, authentication, merchants, and infrastructure. We also learned that trust can't simply come from assuming the AI will always make the right decision, important actions need clear boundaries and explicit rules, not just good intentions.

Strands' model-agnosticism turned out to be a real escape hatch rather than a marketing line: swapping the entire inference backend for this submission was a one-function change, with the tools, the system prompt, and the Telegram layer completely untouched. And the money-safety lesson generalized well beyond WhatsApp: idempotent debits, reverse-only-when-proven-uncharged, always-fresh balance checks, all exist because "just do it" is only a safe default when everything upstream of that decision is verified fresh, never assumed or remembered.

What's next for ASAP

Our next step is expanding the number of services and businesses ASAP can access: more mobility providers, airlines, food businesses, hotels, retailers, and local merchants, so users can reach more of the services they already use through one agent. We also want ASAP to keep getting more accessible across AI platforms and interfaces, while continuing to build our own infrastructure instead of depending entirely on any single platform, including deploying this submission's agent to Bedrock AgentCore and extending it past airtime to the same wallet's other rails.

Our long-term vision is to build the agentic commerce layer for Africa, where users express their intent and ASAP handles the complexity of getting it done.

Built With

• amazon-web-services
• anthropic
• python
• strands
• telegram