Commerce Agent and Impo: built with the Rebyte Agents API

A useful way to understand an agent API is to look at a complete application. Where does the conversation live? Who runs the tools? What happens when someone closes the app halfway through a task?

Two open-source projects make those questions concrete: Commerce Agent, a shopping assistant inside a storefront, and Impo, a personal agent with native mobile clients. Both use the Rebyte Agents API, with different interfaces, tools, and application backends.

Commerce Agent: from a shopping request to a cart

In the ACME storefront, a shopper can describe what they need, compare products, and add a choice to their cart. The response can include product cards, comparison views, and a checkout summary. Those UI elements are part of the application, backed by its catalog and shopping rules.

The Rebyte starter adapts Anthropic's ACME commerce demo. It includes the storefront, a Python backend, Agent configuration, Skills, and the original commerce tool implementations. ACME's catalog is fictional, and checkout produces a summary without placing an order or charging a card.

The integration begins with a saved Agent. Each browser conversation gets its own API Session, which is reused as the shopper asks follow-up questions. The application subscribes to Session events before sending input, then streams the reply into the storefront.

When the Agent needs to search the catalog or change the cart, it requests a function call. The Python host validates the request, executes the corresponding business function, and returns the result to the Session. Presentation functions also run through the host, so the storefront receives structured, validated content it knows how to render.

Tools discovered as they are needed

The saved definition includes twenty commerce functions with deferred loading and an explicit tool_search tool. The model discovers relevant function definitions during the conversation. A catalog lookup and a cart update remain ordinary application functions, with the same validation and shopping rules as the original demo.

Each Session also includes five Skill packages in its hosted environment. The Agent can read their instructions when it needs them. Rebyte allocates the Sandbox when an environment tool is used; calling a catalog function alone does not require one.

This is a useful starting point for a product that already has business operations exposed in code. Keep those operations in the application, describe them as function tools, and let the Agent choose the next step in a conversation. Start with the integration guide, then follow a handoff through the Python adapter.

Impo: a personal agent across conversations and tasks

Impo brings a different set of requirements. A user can talk to a personal agent, delegate a task, receive a briefing, or capture spoken context with Echo. The project includes native iOS and Android clients and a shared backend; a web client is planned.

Impo's backend authenticates users and records accepted work. A server worker connects that work to Rebyte. The main conversation uses a saved Agent for the user, while delegated tasks get independent Sessions with their own Agent configuration. Separating task Sessions lets the application track each job without mixing it into the main conversation's execution state.

The worker subscribes to live events and reconciles Turns and Items with the application's records. The native client receives streamed updates through Impo's own API. Closing a stream ends the subscription; cancelling work is a separate command. This distinction lets a user leave the app and return to recover the conversation history.

The application decides where tools run

Impo dispatches function calls to the system that owns the capability. External-service tools run on the server through Composio. Internal tools can create application tasks. Permitted device tools run on the selected native client, with ownership and capability checks in Impo's backend.

The same boundary applies to background work. Temporal coordinates Impo's briefing schedule and invokes a Rebyte Agent when a brief is due. Echo has a separate audio-upload and Gemini transcription pipeline. Its transcripts contribute evidence to Impo's memory system, which supplies relevant context to later conversations. Rebyte provides the managed Agent execution; Impo owns those application workflows and memory stores.

Developers building a native agent app can explore the architecture guide and Rebyte gateway. The repository makes the boundaries visible: client commands, durable workers, Agent Sessions, tool dispatch, and history recovery.

What these applications have in common

Commerce Agent and Impo both keep application responsibilities explicit. The product decides who the user is, what data they can access, which functions are available, and how results appear. Rebyte manages the Agent's execution and its Session state.

• Sessions follow the product's unit of work. Commerce uses a Session per shopping conversation. Impo separates the main conversation from delegated tasks.
• Function tools connect Agents to existing code. Catalog handlers, cart validation, service integrations, and native capabilities stay with the application that understands them.
• Events connect execution to the interface. Applications use live updates to render progress and results. Impo also reads persisted runtime state to recover after a client disconnects.

You can study both implementations without signing in. Read the API showcase guide for source links and integration details, then follow the quickstart to run your first Session with a Rebyte API key. For React hooks, a chat interface, and a server adapter, see the Rebyte Agent SDK.