• 

• 

• 

• 

Talli helps small businesses and informal traders record and manage customer credit using ordinary speech, text, or Telegram.

Instead of filling out accounting forms, a merchant can simply say, “Adele took goods worth $40 and will pay on Friday,” or “She paid $10 today.” Talli turns those conversations into structured customer balances and transaction histories.

Through WebMCP, a browser agent can securely read the same live ledger, answer questions, identify overdue debts, and prepare proposed financial updates. However, the agent cannot finalize those changes. The merchant reviews and confirms every consequential update inside Talli’s visible interface.

The Problem

Millions of small businesses and informal traders sell goods on credit every day. A customer may take food, clothing, supplies, or other goods and promise to pay later. The business owner needs to remember:

• who took the goods
• how much they owe
• when they promised to pay
• whether they made a partial payment
• how much remains outstanding
• which customers are overdue

Many business owners manage this information using paper notebooks, memory, calculator notes, chat messages, or a mixture of all four.

This creates serious problems. Records can be lost, payments may not be reflected correctly, and business owners can struggle to explain how a customer’s balance was calculated. When several customers have similar names, it is also easy to update the wrong person’s record.

Traditional accounting applications can help, but they are often designed around forms, tables, categories, and bookkeeping terminology. For someone who is busy serving customers and may not consider themselves an accountant, recording a simple credit transaction can feel like administrative work.

The real challenge is not that these business owners do not understand their businesses. The challenge is that most financial software does not work the way they naturally communicate.

The Solution

Talli is a conversational credit ledger built around the way small businesses already talk about customer debt. Instead of completing a long form, a merchant can speak or type naturally:

“Adele took goods worth $40 and will pay next Friday.”

Talli converts that statement into a structured financial record containing the customer, amount, currency, transaction type, and relevant date.

Later, the merchant can say:

“Adele paid $10.”

Talli records the partial payment, updates Adele’s outstanding balance, and preserves the history of how that balance changed.

The merchant can also ask questions such as:

• “How much does Adele still owe?”
• “Who owes me money?”
• “Which payments are overdue?”
• “Show me Adele’s transaction history.”
• “How much have my customers paid?”
• “Mark this debt as settled.”

Talli supports voice, typed conversations, a web interface, and Telegram. The same underlying ledger can therefore remain useful while the merchant moves between the channels they already use.

Talli also understands that financial records require caution. If a request is unclear, Talli does not silently guess. It asks for clarification before allowing the wrong customer or obligation to be changed.

The WebMCP Extension

For the WebMCP Challenge, I extended Talli so that the live website can expose its financial capabilities directly to browser-based AI agents.

Without WebMCP, an agent trying to assist a Talli user would have to inspect the page, interpret text on the screen, locate buttons, fill forms, and simulate clicks. That approach is fragile and can be especially dangerous when the website contains financial information.

With WebMCP, Talli explicitly tells the agent what it can do, what information each operation requires, and which operations are read-only.

The agent can discover structured tools for searching customers, checking balances, reviewing histories, finding overdue debts, and preparing ledger changes. It receives structured results from the same live ledger the person is viewing.

This creates a shared workspace between the merchant, the browser agent, and Talli.

A Typical Human-Agent Workflow

Imagine that a merchant asks their browser agent:

“Check Talli and tell me how much my customers owe me.”

The agent calls Talli’s get_ledger_summary tool and receives a structured summary from the current ledger.

The merchant then says:

“Adele paid $10. Update her balance.”

The agent calls prepare_ledger_mutation, but Talli discovers that several customers match the name “Adele.”

Instead of choosing one, Talli returns clarification_required with a short list of matching customers and their balances. The ledger remains unchanged.

The agent can then ask:

“I found more than one Adele. Which customer made the payment?”

After the merchant identifies the correct customer, the agent prepares the payment again. Talli validates the request and displays a visible review card containing the exact proposed change.

The merchant reviews the amount and customer, then clicks Confirm inside Talli.

Only at that point does the ledger change.

This workflow demonstrates more than an agent operating a website. The agent helps with interpretation and preparation, Talli enforces financial safety, and the human retains final authority.

Why Talli Is a Strong Fit for WebMCP

Talli is a strong WebMCP use case because customer credit management combines repetitive work with consequential financial decisions.

An AI agent is well suited to:

• searching records
• summarizing balances
• finding overdue obligations
• reviewing transaction histories
• translating a natural-language request into a structured proposal

However, an agent should not silently make an irreversible or incorrect financial change.

WebMCP provides the structured boundary Talli needs. It allows the agent to interact with the application through clearly defined tools instead of guessing its way through the interface.

Talli builds on that boundary with three important rules:

1. Read operations can happen directly.
2. Financial mutations must first become proposals.
3. Only the human can confirm a proposal in Talli’s visible interface.

The most important behavior is not simply that Talli knows how to act. It also knows when not to act.

If two customers match a name, an obligation cannot be safely identified, or the ledger has changed since a proposal was prepared, Talli pauses the operation instead of guessing.

This makes WebMCP part of the product’s safety model, not just another way to call backend functions.

How Talli Creates a Better User Experience

Talli reduces the amount of effort required to maintain accurate credit records.

The merchant does not need to learn database fields, accounting terminology, or a complicated menu system. They can continue communicating naturally while Talli and their agent handle the structured work underneath.

WebMCP improves this experience in several ways:

• The agent can access reliable structured data instead of trying to read values from the visual interface.
• The merchant can ask broader questions without manually searching through individual customer records.
• The agent can prepare a transaction while the merchant remains focused on running the business.
• Ambiguous requests produce clarification instead of silent errors.
• Proposed financial changes are shown in a visible, understandable review card.
• The merchant keeps control over the final decision.
• The agent and the person work from the same current ledger rather than separate or outdated copies of the data.

Talli remains usable in browsers that do not support WebMCP. WebMCP is added as a progressive enhancement, so the normal voice, text, web, and Telegram experiences continue to work.

What People and Agents Can Do Together That Was Difficult Before

Before the WebMCP extension, Talli could already understand conversations and maintain the ledger. However, an external browser agent did not have a dependable, structured way to use those capabilities.

Now a person and their agent can work together to:

• inspect the business’s total outstanding credit
• search for a customer without manually navigating the interface
• explain how a customer’s current balance was calculated
• identify overdue obligations
• prepare new credit, payment, or settlement entries
• detect ambiguous customer references
• ask the human to resolve uncertainty
• present the exact financial change for review
• prevent an agent from confirming its own proposal
• keep a record unchanged until the human explicitly approves it

For example, the agent can do the time-consuming work of finding the correct records and preparing an update, while the business owner makes the final judgment.

That division of responsibility was difficult to achieve reliably through ordinary browser automation. WebMCP makes it possible to define the collaboration explicitly.

Safe Financial Delegation

Talli deliberately separates reading, preparing, and confirming. An agent can read ledger information and prepare a proposed change. It can also cancel a pending proposal. It cannot directly confirm a financial mutation because Talli does not expose a confirmation tool to the agent. Confirmation remains a first-party human action inside the Talli interface.

Additional safeguards include:

• strict input schemas
• bounded tool responses
• opaque proposal identifiers
• proposal expiration
• stale-ledger detection
• idempotent confirmation
• one active proposal per session
• isolated anonymous browser sessions
• conservative customer and obligation resolution
• clarification instead of guessing
• validation that a proposed change still matches the current ledger

These controls help prevent duplicate payments, stale proposals, cross-session data exposure, and accidental changes to the wrong customer.

WebMCP Tools

Talli exposes exactly seven browser-native WebMCP tools:

1. get_ledger_summary Returns a concise overview of outstanding credit, payments, and ledger activity.

2. search_customers Searches customer names and aliases without exposing the full ledger.

3. get_customer_balance Returns the current outstanding balance for a safely resolved customer.

4. get_customer_history Explains the transactions that produced a customer’s current balance.

5. list_overdue_debts Finds open obligations that have passed their expected payment dates.

6. prepare_ledger_mutation Validates and prepares a new credit entry, payment, or settlement without immediately changing the ledger.

7. cancel_ledger_mutation Cancels a pending proposal without changing any financial balance.

There is intentionally no confirm_ledger_mutation tool. Agents can prepare work, but only the human can approve it.

How WebMCP Was Implemented

Talli uses browser-native WebMCP through:

document.modelContext.registerTool(...)

When document.modelContext is available, the frontend registers the seven tools with names, plain-language descriptions, strict JSON input schemas, behavioral annotations, and execution functions.

Each tool communicates with Talli’s same-origin application endpoints and returns structured JSON.

Implementation details include:

• strict schemas with additionalProperties: false
• read-only annotations for tools that cannot modify state
• mutation annotations for proposal-related tools
• deliberate marking of customer-originated content as untrusted
• bounded results instead of exposing the entire ledger
• reuse of the browser’s authenticated session
• support for request cancellation through AbortSignal
• duplicate-registration protection
• feature detection for browsers without WebMCP
• same-origin security headers, including Permissions-Policy: tools=(self)
• isolated, signed browser sessions
• visible human review for consequential actions

The WebMCP implementation lives in the browser. Talli does not add a separate backend MCP server and does not rely on DOM scraping or simulated clicks.

Architecture

Talli has four main layers:

• A browser interface for voice, text, ledger viewing, agent activity, clarification, and human confirmation
• A WebMCP tool layer that exposes structured capabilities to browser agents
• A TypeScript/Node service that handles interpretation, validation, customer resolution, proposals, and ledger operations
• Supabase/PostgreSQL persistence for production data, with file-backed storage available for local development

The web application and WebMCP tools use the same ledger state. This prevents the agent from working with a disconnected copy of the user’s information.

Talli is deployed as a Node.js web service on Render and uses HTTPS. Telegram is connected through a separate bot and webhook while sharing the appropriate user ledger after account linking.

Challenges Encountered

Preventing the Agent From Guessing

Names used in informal business conversations are often incomplete or duplicated. A merchant may have several customers named Adele or John.

Talli needed a conservative resolution system that could return a small list of candidates instead of selecting whichever record appeared first.

Designing Safe Mutations

A normal API might immediately write a payment to the database. That was not appropriate for an agent-facing financial workflow.

I introduced a proposal lifecycle so that preparing, reviewing, confirming, cancelling, expiring, and retrying a financial change are separate states.

Preventing Duplicate Financial Changes

A confirmation may be retried because of network delays or repeated clicks. Talli uses the ledger event identifier as an idempotency anchor so that the same proposal cannot be applied twice.

Keeping Browser Sessions Private

Fresh browsers previously risked sharing a default ledger state. Anonymous sessions are now cryptographically random, signed with a server secret, stored in secure cookies, and isolated from one another.

Preserving Existing Product Behavior

WebMCP was added without removing Talli’s existing voice, text, web, and Telegram experiences. Browsers without WebMCP support can still use the application normally.

Accomplishments

• Built a working browser-native WebMCP integration
• Registered seven focused, discoverable tools
• Created a safe proposal and confirmation lifecycle
• Kept final financial confirmation under human control
• Added visible proposal review and agent collaboration activity
• Implemented ambiguity detection with bounded candidate responses
• Prevented clarification-only requests from changing the ledger
• Made confirmation idempotent
• Added stale-proposal and expiry protection
• Isolated anonymous browser sessions
• Preserved web, voice, text, and Telegram access
• Deployed a working version on Render
• Tested the application across unit, integration, browser-tool, storage, session, and mutation scenarios

Verified Demo Journey

The deployed application has been tested with the following workflow:

1. A browser agent discovers all seven WebMCP tools.
2. The agent requests a ledger summary.
3. The agent prepares a $650 credit entry.
4. The ledger remains unchanged while the proposal waits for review.
5. The proposal appears in Talli’s visible interface.
6. The human confirms it.
7. The balance updates exactly once.
8. The agent attempts to record a payment for “Adele.”
9. Talli finds multiple matching customers and returns clarification_required.
10. The candidates are shown, no executable proposal is created, and the ledger remains unchanged.

Telegram account linking and messaging have also been tested successfully with the deployed application.

What I Learnt

The most important lesson from building Talli is that a useful financial agent must be designed around restraint as much as capability.

Giving an agent more tools does not automatically create a better product. A smaller tool surface with clear responsibilities, strict schemas, and safe failure behavior is more reliable.

I also learned that human confirmation should be part of the main product experience. It should not be hidden behind a generic browser prompt or treated as an afterthought.

Finally, WebMCP is most valuable when it exposes real application capabilities and current state. Talli’s agent is not operating a demonstration database or an isolated chatbot. It is collaborating with the person through the same ledger the person can see and use.

Who Talli Is For

Talli is designed primarily for:

• market traders
• neighborhood shops
• home-based businesses
• sole proprietors
• small wholesalers
• social-commerce sellers
• service providers who allow customers to pay later
• business owners who find traditional accounting software too complicated

The product is especially relevant in markets where informal customer credit is common and mobile messaging or spoken communication is more familiar than bookkeeping software.

Privacy and Security

Talli treats ledger records as sensitive information.

The deployed application uses signed, HTTP-only browser session cookies. Anonymous browser sessions are isolated, and public requests cannot select another session by supplying a session identifier.

WebMCP tools return bounded information rather than dumping complete application state. Customer-generated content is treated as untrusted, and financial mutations require validation and human approval.

Secrets such as database credentials, session-signing secrets, model keys, and Telegram bot tokens are stored as server-side environment variables and are not exposed to the browser.

Current Limitations

• Financial confirmation serialization is currently process-local, so the deployed service should run as a single application instance.
• WebMCP functionality requires a browser environment that supports document.modelContext.
• Talli currently supports a focused set of ledger operations instead of exposing every internal capability.
• The language experience still needs broader localization and testing across regional speech patterns.
• The current product is focused on customer credit rather than full business accounting.

These limitations are deliberate and documented. Talli prioritizes a small, dependable financial workflow over pretending to be a complete accounting platform.

What’s Next

WhatsApp Integration

Many small businesses already conduct customer conversations through WhatsApp. A future integration would allow merchants to record credit, receive payment updates, check balances, and receive reminders through a familiar channel.

The integration would follow the same safety model as the web and Telegram experiences: ambiguous instructions would require clarification, and consequential actions would remain reviewable.

More Languages and Local Speech Patterns

Talli currently demonstrates a conversational interaction model, but financial conversations vary significantly across countries, languages, accents, and local business terminology.

Future versions will support more languages and regional expressions, beginning with languages commonly used by Talli’s target users. This includes improving recognition of mixed-language conversations, local currency expressions, informal names, and culturally specific ways of describing credit.

Smarter Payment Reminders

Talli could help merchants identify overdue debts and prepare respectful, personalized payment reminders for review before they are sent.

The merchant would remain in control of the message, recipient, tone, and delivery time.

Low-Bandwidth and Offline Support

Many target users work in environments with unreliable or expensive internet access. Future versions could support offline-first transaction capture and synchronize records once connectivity returns.

Additional Communication Channels

Beyond Telegram and WhatsApp, Talli could support SMS and other messaging platforms commonly used by small businesses.

Receipts and Evidence

Future versions could generate simple payment acknowledgements and attach supporting information such as receipt images, voice notes, or transaction references to ledger events.

Business Insights

Talli could provide understandable insights such as:

• customers with consistently late payments
• total credit issued over time
• collection rates
• expected incoming payments
• customers approaching agreed credit limits

These would be presented in everyday language rather than accounting jargon.

Carefully Expanded Agent Capabilities

More WebMCP tools may be added for reminders, reconciliation, and reporting, but only when they can be modeled with the same strict safety guarantees.

The goal is not to maximize the number of tools. The goal is to expand what people and agents can accomplish together without weakening human control.

Built With

• biome
• css
• git
• github
• html
• javascript
• node.js
• openai
• postgresql
• render
• supabase
• typescript
• vitest
• webmcp
• zod