Pipipt Brain
Keep AI products running—and improving.
Give a device a recognizable companion identity. Connect conversation to memory and action, while keeping people in control. Bring those capabilities together in a product that can keep improving.
Digital life · Product development directionSee how the capabilities work together ↓
One identity. An ongoing relationship.Companion experience preview · Static avatar and preset dialogue; no live service connected.
Six outcomes, from a product idea to everyday use
01 Define the product and its relationships
- Product lifecycleAlign hardware, software and versions around one purpose.
- Users, families & appsMake control, access and relationships clear.
02 Connect interaction to real action
- Connectivity & runtimeCoordinate devices, apps, cloud and edge.
- AI interaction & behaviorConnect listening, response, memory and action.
03 Keep improving after delivery
- Release & operationsMake updates, feedback and recovery part of operation.
- Trust & delivery evidenceMake permissions, results and evidence traceable.
Shared capabilities behind the experience
One foundation. Different product forms.
Select a capability in the diagram to see the problem it solves and how it fits. Intelligent devices can use just the parts they need.
Pipipt Brain System goals · Eight capability families
Give the experience the right body
Combine computing, display, audio, connectivity, sensing, storage, power and privacy components around the experience the product needs.
Current scope: Hardware adaptation targets BK7258, the ESP32 family, and Android / Linux devices. Supported chips, boards and feature combinations are confirmed for each product; availability is not universal across platforms.
Compatibility and feature notes
The hardware architecture spans MCU firmware, Android devices and Linux devices. ESP32 and BK7258 describe specific chip and board paths, not complete products.
Review display and touch, microphones and audio output, Wi-Fi / Bluetooth / 4G, cameras and other sensors, RTC, power and physical privacy switches. Installed hardware, supported functions and permission to use them are separate facts.
Allocate work across cloud, edge and device according to latency, resources and privacy. Modular engineering does not promise arbitrary hot swapping or automatically generated production designs.
Make listening and response work together
Let people finish, interrupt and continue naturally. Keep speech, playback and avatar states coordinated so the product does not continue an outdated response.
Current scope: Verify voice against a specific hardware, firmware, service and network combination. Board experiments do not establish a complete voice experience across all products. Private ASR / TTS is an explicit deployment direction; installation, quality, capacity and recovery require acceptance for the selected models and environment.
Compatibility and feature notes
Design the complete turn: capture, understanding, response, interruption and continuation. Attentive listening is central; continuous speech is no substitute.
Expressions, movement and lip sync should follow actual listening, thinking and speaking states. An animation does not prove audio was played.
Match responses to purpose and cost
Choose models and capabilities for the product’s purpose, with explicit tradeoffs between response quality, latency, data use and cost.
Connected providers: Qwen, Gemini, DeepSeek, Z.AI, Doubao, Kimi and OpenAI. Choose suitable models and capabilities for each product.
Compatibility and feature notes
Organize routing, policies and product evaluation for conversation, images, perception and content tasks. Knowledge retrieval must respect the subject and permitted purpose.
Cloud, private deployment and local execution are distinct adaptation paths. Configuration alone does not verify a model, region or operating mode.
Give actions permission and an outcome
Turn a request into a verifiable action: establish who is asking, what is allowed and what actually happened.
Current scope: Some authorization and interface foundations exist; coordination across tools and complete execution workflows are still in development.
Compatibility and feature notes
An agent clarifies ambiguous intent. Tools, MCP and device actions may execute only within current identity, purpose, authorization, risk, content rights, cost and hardware constraints.
Allow, deny or request confirmation according to risk; handle cancellation, withdrawal, retries and failures. Discovering or configuring a tool does not grant execution rights.
Execution evidence links decisions and calls to actual effects, distinguishing completed, partial, failed and unconfirmed results.
Build continuity with memory people control
Let a product remember stories and preferences people choose to keep, with ways to correct mistakes, stop use or delete them.
Current scope: A limited conversation-context foundation exists; long-term memory and its management and deletion features are still being developed and validated.
Compatibility and feature notes
Govern active context, chat history, durable personal facts, relationship references and business knowledge separately. Personal memory does not mean keeping every conversation indefinitely or mixing it with enterprise knowledge.
A durable memory starts as a candidate with a source. Check its subject, purpose, consent, conflicts and retention before admitting it for later use.
App controls are intended to support viewing, correction, retention, stopping collection or use, withdrawal and deletion. Withdrawal and deletion must also address derived summaries, indexes and caches. Children’s products use stricter limits.
Give a companion identity and expression
Organize a name, forms of address, personality, voice, 2D / 3D avatar and relationships around a stable digital-life identity that people can recognize.
Current scope: Digital life and personalized expression are in development, with the aim of keeping a companion’s identity consistent across devices. Compatibility between avatars, voices and devices is confirmed for each product.
Compatibility and feature notes
Digital life connects conversation, governed memory, relationships and authorized behavior. Avatars provide expression; apps, screen devices and robots can provide a body. Identity continuity across bodies does not imply unrestricted memory sharing.
People can choose an interaction style and materials they have rights to use, including voices, photos or avatars. A relative’s representation is not that person, and every representation need not be a separate digital life. Uploaded material is not a finished interactive companion.
The app provides user controls and may also host interaction. Android / iOS phone apps and Android device runtimes are separate adaptation targets. Requested settings must be distinguished from what actually took effect.
Keep improving after delivery
Include long-term operation in the product, from factory setup and release through updates and recovery.
Current scope: Some usage-management and update-interface foundations exist; device updates, recovery and production readiness still need validation on physical devices.
Compatibility and feature notes
Manage hardware and software versions, compatibility, factory configuration and release processes. Check conditions before an update, then verify the actual version and effect.
Connect usage, quotas, cost, failures and recovery to specific products and execution facts, so feedback can inform the next version.
Make trust part of everyday use
Help people understand who uses their information, for what purpose and when they can stop it. Help teams explain what a product did and what remains incomplete.
Current scope: Selected identity, authorization and engineering paths can be checked. Product-wide privacy, safety and reliability acceptance remains to be completed; this is not a certification or blanket compliance claim.
Compatibility and feature notes
Apply current consent, content and likeness rights, purpose, retention and access boundaries to interactions and actions. Safety and compliance requirements must be applied to the actual product, region and release scope.
Adults and older people retain their own decision rights. Family or care relationships do not automatically grant every permission. Children’s scenarios use applicable guardian rules and stricter limits.
Keep only necessary execution facts and minimize private text and raw materials. Verify real effects, permission changes, failure and recovery rather than relying on ordinary logs alone.
Seven model providers connected. Choose for your product.
Model choice and deployment
All seven providers are connected. Qwen, Gemini, Doubao and OpenAI are integrated and operational. Choose models to suit the product and use case.
Model versions, regions, capabilities and deployment are configured for each project. Cloud access and private deployment are separate choices.
Put capabilities into everyday life
An ongoing companionship starts with something worth sharing.
Example: an older person recalls cycling to the sea. Choose a stage to explore how listening, response, action, memory and continued operation fit together.
Interaction example only: no model calls, recording, storage or sending of data. Switching language or reloading resets the example.
Listen first. Make room for the next thought.
The robot listens before responding to the person’s feelings. When the person adds something, the old response gives way to the new thought. The avatar follows the actual voice turn.
Familiarity comes from consistent expression and attention, not constant speech or pretending to know experiences never shared.
The same companion, with clear boundaries.
Choose the model and response style using the scenario, authorized context and product rules. Recollection must draw on permitted memory, without inventing the person’s experiences.
If a relative’s photo or voice is used, establish material rights and scope first, and clearly present it as a virtual interactive representation.
An accepted request is not a completed action.
“Play the story I saved last time.” Clarify which story, then check current permissions, content and device state. Report what actually happened after execution.
Receiving a request, server processing, device execution and the person hearing playback are different facts. An uncertain outcome must not be reported as completed.
- Permission
- Awaiting confirmation
- Device result
- No example request issued
This page only simulates authorization and action results. It does not control devices or play audio.
Keep the story. Keep the person in control.
Respond to the present moment first, then propose a memory with a source. The person or appropriate decision-maker chooses whether and why to keep it, with later controls to view, correct, stop use or delete.
Durable memory and cross-body recall are development goals. Switching devices does not automatically open all private memories.
A memory candidate with a source
The complete long-term memory, correction and deletion-propagation loop remains a development and verification goal. These states exist only in this page.
Versions change. The relationship can continue.
Maintain identity across supported bodies while respecting their actual capabilities. After an update, check settings, permissions and behavior; recover from failures and explain the outcome.
Cross-device continuity and recovery require verification for each combination. Unsupported expression must not be shown as an applied setting.
Capabilities in everyday life
How these capabilities come together in a device.
Product samples show how capabilities work together. For your hardware, app or team, we assess models, device adaptation and deployment scope per product.
Product design practice: organize the device, parent app and AI around real-world action.
Product form and roles · Example
Product direction: explore how sound and virtual expression shape an experience in a space.
Product form and roles · ExampleCapabilities can also be combined for older adults’ companionship and young people’s personal expression.
Digital life, durable memory, cross-device avatars, complete Agent execution and user-rights controls remain development goals. Availability depends on the product, board, firmware and service version.
Hardware compatibility and current progress
- BK7258
- Specific board experiment passed
Experiments have been recorded for a specific BK7258 board and firmware; production validation is not complete.
- ESP32-C3
- Foundation experiment verified
ESP32-C3 + ES8311 has build, flashing and startup records; full voice, networking and remote updates still need further validation.
- ESP32-S3
- Hardware design candidate
The ESP32-S3 children’s routine product is still in hardware design; complete-device and production validation are not finished.
- Android / Linux devices
- Architecture & adaptation targets
An adaptation path for Android / Linux devices. Model, OS version and feature scope need project-specific confirmation.
- Platform & services
- Some functional foundations exist
Some foundations exist for conversation context, model policies, authorization, usage and update interfaces; complete agents, long-term memory and whole-device capabilities still need development and validation.
Compatibility is confirmed for the board, firmware and service versions used in each project.
Connect to your product and team
Start with what you have. Add the capabilities you need.
Existing hardware, apps, brand characters or content can be a starting point. Plan cloud, private or hybrid deployment separately for foundation services, speech recognition and speech synthesis.
What you already have
- Hardware and devices
- Apps and development team
- Character, voice and content rights
Services to integrate
Deployment and responsibilities
- Cloud / private / hybrid
- Data flows and access boundaries
- Acceptance, operation and updates
Private deployment is a project-specific adaptation and acceptance path. Model licensing, compute, networking and operational responsibility must be confirmed. Cloud integration does not mean that model can be privately deployed.