AIBE — AI Business Engine
Specialized agents need coordination, contracts and boundaries.
The repository contains an earlier execution record. This review extracted its summary and file hash without rerunning the suite. It is author-provided historical evidence, not independent verification or a current measurement.
Problem and proposal
AIBE investigates a different problem from StratHUB: coordinating specialized agents that receive tasks, use models and tools, and share context. Adding prompts alone does not address responsibility assignment, failures, costs or decision tracking.
AI Business Engine is an experimental platform for organizing this work. The code combines an agent catalog and lifecycle, task routing, event communication, budget controls and an operations interface. This private personal project is described through its engineering mechanisms.
Architecture and system startup
A central orchestrator initializes shared infrastructure, the tool registry and agents. Creation uses a catalog/factory and can select groups or exclude agents. Startup follows tier order, with state monitoring and coordinated shutdown.
The foundation is asynchronous Python: FastAPI at the API boundary, NATS for messaging and clients for memory, models and persistence. Application lifespan connects the orchestrator, task tracker and WebSocket event bridge. These boundaries distinguish runtime responsibilities from interface concerns.
Agents: identity, state and lifecycle
The base class defines identity, role, state, budget and shared capabilities. Agents can register handlers, start asynchronous loops and stop them through task cancellation and collection. Loop exceptions increment counters and are logged, distinguishing interrupted work from completed delivery.
The catalog groups specialties such as product, research, security, finance and marketing. These roles describe intended functions within the experiment; they are not human professionals, real operating departments or guarantees that every agent integration is complete.
Delegation: choosing who handles the task
Task routing uses task specifications and delegation rules. An explicit target takes precedence; otherwise, task type determines preferred agents and fallbacks. Registry availability participates in selection. If no eligible agent exists, the flow raises an error rather than inventing an assignment.
The tracker follows submitted, assigned, running, completed and failed states. In the reviewed implementation it stores records in memory. Database repositories and persistent models also exist, but the presence of SQLAlchemy alone does not make all interface state durable.
Model routing and structured responses
Model routing is separate from agent selection. ModelRouter chooses a model chain by task type, integrates OpenRouter and accepts structured-output parameters. Model selection and unavailability handling are centralized rather than duplicated in each agent.
The code includes circuit breakers, configured fallbacks and token, cost and duration logging. Context reduction estimates size, retaining initial and recent messages while removing middle sections. This heuristic bounds context but is not guaranteed semantic summarization.
Budgets and controlled degradation
Inference cost is treated as system state. The project includes per-agent budgets, reservation before operations, reservation release and actual-cost recording, with asynchronous locks coordinating changes. Budget checks can guide model downgrades or call suspension at configured thresholds.
These components remain in development and their complete runtime integration requires verification. The engineering goal is to prevent concurrency and repeated attempts from hiding costs. No percentage savings or real production budget is claimed without measurement.
Messages, integrity and loop prevention
The bus uses typed task and event messages. Code includes HMAC-SHA256 signing and integrity verification, telemetry middleware and loop protection. These mechanisms aim to make agent communication identifiable and prevent indefinitely self-feeding message chains.
Signing protects against alteration when correctly configured and applied; it does not replace authentication, authorization or tool isolation. Describing these mechanisms is not a security certification. The complete architecture needs evaluation before handling higher-impact data or actions.
Memory, tools and persistence
The memory client defines storage, recall and semantic-search operations by namespace. OpenViking integration depends on an external service and permits mock mode when unconfigured. Namespaces and metadata organize shared and agent context without making memory an always-available capability.
A tool registry centralizes discovery and execution; SQLAlchemy/PostgreSQL models and repositories represent tasks, meetings and costs. Redis and telemetry components complement the infrastructure. These modules demonstrate component design and implementation; durability, availability and end-to-end integration require further validation.
Supervision, meetings and operations interface
The supervisor inspects state, bounds restart attempts and uses cooldown to avoid uncontrolled recovery loops. The meeting engine combines participants, agendas, turns and decision records as a coordination mechanism. Degradation paths address unavailable components.
The Next.js/React/TypeScript interface exposes agent, task, cost and metric views. FastAPI provides corresponding routes and a WebSocket bridge distributes updates. The interface makes runtime activity visible to an operator; a screen or endpoint alone does not prove that every underlying flow is complete.
Verification, boundaries and demonstrated skills
The repository contains suites for types, configuration, routing, budgets, messages, tools, supervision, degradation, agents, delegation, meetings and API behavior. Many scenarios use mocks to isolate dependencies. This review examined test structure and assertions without claiming a passing run or unmeasured coverage.
Contract/integration differences, experimental components and mock modes remain. AIBE is therefore presented as a project in development, not a proven autonomous operating business. It demonstrates asynchronous APIs, state modeling, LLM integration, event-based coordination, observability and resource controls. Private code and configuration are not published here.
Private repositories. Authorized summaries; source code is not distributed here.