How far you actually get in a day with an in-app agent

The claim in the original title is true and it needs a caveat in the first paragraph rather than the last. A day gets you a working spoken turn against your real data. It does not get you a feature you would put in front of paying customers, and the gap between those two things is where every project in this category actually lives.

Nordic APIs made the general point about developer funnels years ago and it applies here exactly. Writing about time to first call (9 November 2021), Art Anthony notes: “Making a first call is very different from someone becoming an active user.” Swap “active user” for “shippable feature” and you have this post.

What the day actually contains#

The first hour is mechanical. Add the package, set the microphone permission, confirm it launches. The second is your auth layer: hand the SDK a token getter that returns the current value rather than one cached at startup, because a stale token fails in a way that reads as a network error.

The third hour is the one people remember. Describe one read operation as a tool, ask a question out loud, and watch your own data come back as something on screen. That is the demo everyone will ask you to repeat.

Hours four to six are the first real lesson, and they arrive as a surprise. The agent keeps choosing the wrong operation, or inventing an argument, and the fix is in the description rather than the prompt. Anthropic’s guidance on writing tools for agents (11 September 2025) names the reflex to resist: “More tools don’t always lead to better outcomes.” A small set of well-named operations that map to real user goals beats a generated wrapper around your whole API.

By the end of the day you have a working read-only agent over one or two operations. That is a genuine milestone and it is not a feature. What the SDK owns and what stays yours is worth reading before you plan the rest.

Why the integration is not the critical path#

Draw the critical path and the SDK disappears from it. What remains is a sequence of decisions: which operations the agent may call, what they are named, which of them may write, what the approval shows, and how you will know whether any of it works.

Those are product decisions with security implications, and they need a product person, an engineer and usually someone from risk in the same room. Scheduling them as an engineering task is why projects in this category slip.

The work that fills week two#

Naming and separating operations takes longer than it sounds. Two operations that sound alike to a human sound identical to a model, and the fix is renaming them in a way that makes the distinction explicit in the name itself. Namespacing helps here, and Anthropic recommends it directly in the same guidance.

Error text is the second job. A tool that returns “400 Bad Request” tells a model nothing. One that returns “no merchant id was supplied; ask the user which account they mean” tells it what to do next, and the difference shows up immediately in completion rates.

Deciding what may write is the third, and it is not an engineering decision. Someone has to say that changing a delivery address is a tap and settling a balance is a biometric prompt, and someone has to own that decision afterwards. Confirm cards and biometrics is the reference for how to tier it.

Evaluation is the fourth and the one most often skipped. Write thirty questions with known correct tool calls and run the whole set repeatedly rather than once. Repeatedly matters: a model that answers correctly on the first attempt and incorrectly on the third is not a 50% feature, it is an unpredictable one, and unpredictability is what users remember.

What users already expect#

Two findings from Stack Overflow’s 2025 developer survey are worth holding while you design the error paths. Of the 33,662 who answered it, 84% use or plan to use AI tools. Of the 31,476 who answered a different question, 66% named “AI solutions that are almost right, but not quite” as their biggest frustration, and of the 33,244 asked about accuracy, fewer than a third said they trust it.

Your users will stop being impressed that an assistant exists within a week, and will go on noticing how it behaves when it is wrong for as long as they use it. Design that path first, and make sure a wrong answer is cheap to correct in one follow-up rather than requiring the user to start over.

The same caution applies to expectations about resolution. Gartner’s survey of 5,728 customers found that only 14% of customer service issues were fully resolved by self-service channels. Plan the handoff to a human as a first-class path rather than as a failure state.

The problem you will not see coming#

Discoverability is the defect that shows up in week three and nobody budgets for. A user opens the assistant, sees a microphone, and has no idea what it can do, so they ask something it cannot answer and never open it again.

The cheapest fix is a short list of real things to say on the opening screen, drawn from operations you know work. The second cheapest is a follow-up suggestion after every answer. Both are content decisions rather than engineering ones, and both need someone to sit with the transcripts and notice what people tried to ask.

A realistic schedule#

Day one, the integration and one read operation. That is the afternoon the original title promised.

Week one, the tool surface: every operation the agent may call, named, shaped, with error text, and a first pass at the question set.

Week two, the write path: what may write, what the approval shows, how it is tiered, and what happens when the model picks wrong.

Week three, a slice of real users and the first transcripts. Reading those transcripts changes the tool surface more than any amount of internal testing, and you should expect to rewrite descriptions afterwards.

After that it is maintenance, which does not end. The complete guide covers the five layers underneath all of this.

The day above is written from the iOS side because that is where our own captures come from. The shape holds on the other platforms, with the platform-specific traps written down separately: the Flutter route and the GenUI comparison if you are choosing between Google’s orchestration layer and a plugin over the native SDKs, and the React Native bridge if you need to know which Expo flavour you are on before you plan anything.

Who needs to be in the room#

The decisions on the critical path are not all engineering decisions, and treating them as though they are is the most common way this project stalls.

Someone from product decides which operations exist at all, because the list is a statement about what the assistant is for. A list assembled by whoever happened to be writing the code becomes a list of whichever endpoints were easiest to wrap.

Someone from design decides what the confirm card shows and where the launcher lives. Both are surfaces users will judge the whole feature by, and both are easy to leave as defaults until a week before launch.

Someone accountable for risk decides which operations may write and what each one requires. In a regulated product they will need to see the trust boundaries drawn before they can sign anything, which is a document worth having early rather than producing under pressure.

And somebody has to own reading the transcripts after launch. That job has no natural home, it is the highest-value work in the first month, and it will not happen unless it is assigned.

The honest version of the promise#

An agent SDK compresses the part of this project that used to take quarters into an afternoon. It has no effect at all on the part that was always going to take weeks, because that part is your product rather than your plumbing.

That is still a good trade. It just is not the trade the category usually advertises. Connecting the agent to the backend you already run is where the real work starts.

Sources#

• Nordic APIs, Why time to first call is a vital API metric, 9 November 2021. Accessed 12 September 2026.
• Anthropic, Writing tools for agents, 11 September 2025. Accessed 12 September 2026.
• Stack Overflow, 2025 Developer Survey: AI. Accessed 12 September 2026.
• CX Today, Only 1 in 7 customer service queries resolved with self-service, Gartner study finds, 19 August 2024, reporting a Gartner survey of 5,728 customers. Accessed 12 September 2026.