Edge runtime
A TypeScript application deployed on Cloudflare Workers, with request handling, scheduled work and platform integrations running in an edge environment.
← Back to selected work
Independent project · Deployed system
AI systems · Product execution · Agentic development
Bizli AI.
A multilingual AI companion built as a live, tool-using system—not a single prompt wrapped around one model.
Bizli combines conversational model orchestration, persistent memory, external tools, vision, platform interfaces and a separate diagnostic layer. The project is designed around continuity and resilience: when providers, models or tools change, the system has mechanisms to detect, route around and report failures.
B
Why Bizli exists. Bizli is named after my cat. What began as a personal memorial became a sustained engineering project: building a digital companion that can converse, remember, use tools and remain available to other people.
System overview
Several systems working as one product.
The interesting part is not any single API. It is the coordination between the model layer, memory, tools, interfaces, fallback paths and operational controls.
Model orchestration
Groq is the primary conversational provider. If its route is unavailable or constrained, the runtime can fall back to Cerebras, OpenRouter and Cloudflare Workers AI. These fallback paths provide reduced, text-only functionality rather than full tool parity.
Independent diagnostic layer
A separate Gemini-powered Lab handles diagnostics and quality analysis rather than sharing the main conversational brain.
Persistent memory
Cloudflare KV holds bounded short-term session history and operational state. Supabase PostgreSQL stores selectively extracted longer-term memories, retrieved through embeddings and semantic matching, with an importance-ranked fallback.
Tool execution
A model-directed interface exposes 14 registered function tools in the current source. The model chooses when a tool is appropriate; dedicated TypeScript handlers perform the actual operation.
Observability and testing
An operational dashboard exposes provider and model health, quotas, errors and test results. Scheduled jobs refresh provider/model discovery, run behavioural probes and generate diagnostic improvement proposals for human approval.
Architecture
Designed for provider change and partial failure.
Model availability, quotas and API behaviour change. Bizli's routing layer is built to respond to that reality rather than assume one provider will always work.
01 · Primary conversational routeGroqKey/model rotation · health tracking · quota-aware selection
Fallback 01CerebrasIndependent provider path
Fallback 02OpenRouterDiscovered free-model pool
Last resortCloudflare Workers AIBasic conversational fallback
Separate diagnostic planeGemini-powered Lab · monitoring · test evaluation · improvement proposals
The provider roles above describe the current repository's documented design. The active model catalogue is dynamic and may change as provider availability changes.
Engineering work
Reliability is an ongoing engineering task.
These are concrete mechanisms visible in the published TypeScript source—not claims of custom-trained foundation models or proprietary AI research.
Provider and model discovery
Scheduled probes query provider model catalogues, test candidates and persist the active models. Unavailable models can be dropped and newly available candidates adopted without editing the model list for every change.
Quota-aware routing
The primary provider path tracks usage at key-and-model level. Soft thresholds, cooldowns and health state help the router avoid constrained key-and-model combinations and reduce the likelihood of rate-limit failures.
Failure classification and recovery
Different failures require different responses. The code distinguishes request-size errors, rate limits, provider failures and model-health problems instead of treating every failure as the same retry condition.
Memory retrieval and continuity
Short-term conversation history is bounded and session-aware. Longer-term memories are embedded and retrieved by relevance, with importance-ranked retrieval when embeddings or semantic search are unavailable.
Behavioural test battery
The current source defines a 12-probe suite covering language matching, identity, tool use, privacy, hallucination resistance and conversational behaviour. Six probes run every six hours, rotating through the suite so the full battery cycles every twelve hours; a separate model evaluates the responses.
Human-approved improvement loop
A daily diagnostic report analyses recent errors and test outcomes, then proposes small behavioural-rule improvements. The proposals are sent for explicit approval; the live assistant is not silently changed by the diagnostic model.
Product capabilities
What people can actually use.
The conversational layer can answer directly or decide to invoke a registered tool. Tool execution is handled by explicit TypeScript functions connected to external services.
- ↗Multilingual conversation and language-aware response handling
- ↗Live web search with provider fallback and source links
- ↗Weather, time, currency, market prices and entertainment data
- ↗Image understanding and Telegram profile-photo analysis
- ↗Persistent user memory with semantic retrieval
- ↗Telegram and browser-based chat interfaces
- ↗Games and conversational interactions
- ↗User controls, account flows and administrative tooling
My role and development method
Directed through an agentic workflow.
I did not begin with prior software-engineering knowledge. I began with a vision and learned through building. When I encountered technical limits or an approach failed, I investigated alternatives, experimented, evaluated the results and adapted. Over time, this became a more systematic way of learning and executing.
Founder & Project Lead
Learning through building, then directing execution.
I define product requirements, set priorities, direct implementation through coding agents, assess proposed changes, investigate failures, make architectural and integration decisions, and evaluate the deployed system.
I did not begin with a formal software-engineering background. I began with a vision and learned through building. When I encountered technical limits or an approach failed, I investigated alternatives, experimented, evaluated the results and adapted. Over time, this became a more systematic way of learning and executing.
My working cycle: Envision → Investigate → Experiment → Evaluate → Adapt → Implement → Repeat.
Human-ledRequirements, priorities, product decisions, acceptance and deployment direction.
Agent-assistedCode generation, refactoring, debugging support and implementation tasks under direction.
Evidence-ledRepository history, TypeScript source, test logic, deployment endpoints and operational documentation.
Explore the live project
Read the implementation. Try the system.
The repository is public so the technical work can be inspected. The Telegram bot provides a direct way to interact with Bizli.
Technical summary prepared from the public repository's README and selected TypeScript modules, reviewed on 7 November 2026. Provider availability and deployed configuration can change. This page does not claim independent security certification, formal load testing or a third-party code audit.