01 / Perception
Business context enters the engine.
The analyst reads the dataset, schema, searches for data-quality issues, and the decision behind the request before it picks an analytical route. The same dataset can power five different deliverables. The engine only knows which to build once it understands what the client is actually deciding.
What gets captured
- Files, columns, and quality checks
- Business objective and target audience
- Decision being made downstream
- Interpretability of models, i.e. no black boxes
- Existing definitions, KPIs, and naming conventions
What this enables
- Routing logic chooses the right analytical path
- Data issues get flagged before computation
- Deliverable format matches the consumer
- Definitions stay consistent across reports
Nothing is computed until the engine knows what the answer is for.
02 / Cognitive Routing
The architecture adapts to the problem.
A churn question, a revenue forecast, a fairness audit, or a record-comparison workflow should not run through the same path. The analyst assembles a custom topology of modules. Lightweight routes for clean and simple questions, deeper reasoning paths for ambiguous ones.
What gets captured
- Problem type (forecast, classification, comparison, EDA)
- Data complexity and volume
- Prior decisions the user has made on similar work
- Prior metrics or suggestions
What this enables
- Lightweight routing for simpler problems
- Deeper reasoning paths for more complex issues
- Specific modules are used based on the problem class
- Cost and delivery time is based on the problem itself
The engine adapts its depth to the problem. Light routes for simpler questions, deeper reasoning for ambiguous ones.
03 / Tool Execution
The agent guides. The engine computes.
The LLM doesn't invent numbers. Deterministic Python modules calculate metrics, train models, run statistical analysis, generate tables, and render charts. The analyst's job is choosing which tool, the tool's job is being correct.
What gets captured
- Module and tool selection rationale (why this model, this test)
- Inputs, parameters, and random seeds
- Intermediate dataframes and transformations
- Run-time, errors, and convergence diagnostics
What this enables
- Every number is computed by tested code, not generated by the model
- The same inputs produce the same result
- Model assumptions are documented, not hidden
- Consistent performance over several iterations
Numbers come from controlled code paths, not from a large language model.
04 / Memory
The system learns how the user decides.
Feedback becomes a signal about what was useful, what got pushed back on, and what the client actually acts on. The analyst builds a profile of how a specific organization thinks. The terminology, preferred metrics, default time windows, the shape of a ‘good’ deliverable.
What gets captured
- Per-deliverable preference and written feedback
- Edits made to recommended actions
- Accepted vs. rejected suggestions
- Follow-up outcomes after decisions ship
- Reusable definitions, segments, and templates
What this enables
- Future projects open with the right defaults
- Repeat work skips redundant clarifying questions
- The analyst opens each project already knowing how your team works.
- Patterns of effective work compound over time
Memory is reviewable and editable while autonomous self-modification is a choice.