THYNKR RSI · Research leadership
Research & development
Toward AI systems that improve with evidence, and never grant themselves authority.
THYNKR RSI is the research initiative I lead at Thynkr Systems. It asks a practical question: can an AI system help us find measurable improvements to the systems it runs on, test them properly and carry the lessons forward, while accountable people keep control of every consequential change?
THYNKR RSI is a research and development direction. It is not a product, a service or a commercially available capability, and no autonomous self-improvement engine is deployed. No research results have been published or independently validated.
§01Vision and objectives
Improvement should be measured, not asserted.
Most AI systems answer the request in front of them. Very few can show whether the system around them has become more reliable, efficient or useful over time. My interest is in closing that gap with engineering discipline rather than claims of unrestricted autonomy.
The research objectives I have set for the initiative are deliberately modest and testable:
- Baselines first. Define auditable measures of quality, cost, latency and reliability before recommending change.
- Evidence-backed proposals. Every suggested improvement explains its expected benefit, its risks and the evidence needed to accept it.
- Controlled experiments. Candidates are compared in isolation against reproducible tests, measuring regressions as well as gains.
- Accountable change. Material changes pass human approval and normal release controls, with a route back.
§02Relationship to Thynkr Systems
Research grounded in real products.
THYNKR RSI is a Thynkr Systems initiative. I set its architectural direction as founder and chief architect, and the work is carried out with Thynkr’s engineering effort, not as a solo project.
It draws on the products we build and operate. Those products keep responsibility for their own data, users and business rules; a shared intelligence layer has to respect those boundaries rather than merge customer data or acquire unrestricted operational access.
Thynkr Systems describes the research programme, its governance direction and its roadmap on the company website. This page sets out my architectural view and the principles I am applying.
§03Architecture
Two layers with different jobs.
The design separates the system that does AI work from the system that decides what AI is allowed to do. Neither layer should be able to quietly expand the other’s authority.
Brain — shared AI intelligence and execution
Brain is Thynkr’s internal AI orchestration foundation. Its role is to perform authorised AI work and produce the evidence needed to judge the result.
Exists today: a router that selects configured model routes and enforces operational controls.
In development: task classification, model evaluation, structured AI jobs, cost-aware orchestration and cross-product integration.
WorQ — governance, approval and evidence
WorQ is a live Thynkr product for governing agent and tool activity: what an agent may access and do, which actions need human approval, and what evidence is kept.
Exists today: governance for controlled agent and tool activity, human approval and reviewable evidence.
Planned: owner-level oversight as the home for RSI observations, proposals, evaluations and decisions.
§04Model routing and orchestration
The right model is a measured choice.
I do not assume the largest or most expensive model is the best one for a task. Multi-model orchestration should choose and coordinate models according to the task, the quality it needs, privacy constraints, reliability, latency and cost, and then check the result.
That makes routing a natural first subject for evidence-led improvement: a routing policy can be observed, compared with an alternative in a controlled test and changed only when the evidence supports it.
§05Evidence and controlled experimentation
The target improvement loop.
This is the loop the research is working towards. Its stages are being researched and developed; it does not currently operate as a complete loop in production.
- ObserveCollect permitted signals such as outcomes, quality assessments, latency, cost and policy events. Set the baseline.
- ProposeDescribe an opportunity, the components affected, expected benefit, uncertainty and the evidence required.
- TestEvaluate candidates in isolated experiments against reproducible cases, including regressions.
- ApproveRoute material change to accountable people through established engineering controls.
- MeasureCompare real outcomes with the baseline, keep an audit trail and revert what misses its safeguards.
§06Human approval and accountable change
More capable must not mean less accountable.
- No self-granted authority. A system that proposes a change cannot approve its own expanded permissions.
- Independent checks. A proposal is not accepted on the proposing model’s own assessment.
- Defined scope. Observation and experiments run only within approved data, systems and resource limits.
- Reversible change. Version history, validation and a credible rollback path come with every engineering decision.
- Reviewable evidence. The basis for a recommendation, experiment or approval can be inspected later.
§07Implemented and planned
What exists, and what does not yet.
| Capability | Status |
|---|---|
| Configured model routing and operational controls (Brain) | Existing foundation |
| Agent and tool governance, approval and evidence (WorQ) | Live product |
| Cross-product baselines and approved operational signals | Planned |
| Evidence-backed improvement proposals with owner review | Planned |
| Isolated comparative experiments and regression analysis | Planned |
| Human-authorised application with rollback | Longer-term objective |
| Improving the improvement methods themselves | Exploratory research |
No dates or guaranteed functionality are implied. Readiness claims change only when capabilities are independently validated.
§08Future research
Evolutionary methods, inside explicit boundaries.
Longer term, I am interested in evolutionary approaches that generate and compare many candidate solutions, such as alternative agent strategies, prompts, algorithms and routing policies, and in whether an improvement engine can become better at proposing and evaluating its own changes without gaining the ability to rewrite its permissions, suppress independent tests or deploy material changes on its own.
Published work from Sakana AI informs these questions, including its Recursive Self-Improvement Lab, Darwin Gödel Machine, ShinkaEvolve and Fugu model orchestration.
These are third-party publications I follow. There is no partnership, endorsement, licence or technical integration between Sakana AI and Thynkr Systems, and none of this work is a component of THYNKR RSI.
§09Technical philosophy
Three rules I hold the work to.
Measure before you change.
No proposal without a baseline and the evidence that would prove it wrong.
Authority is never self-granted.
Capability can grow; permission to act on it stays with accountable people.
Every change needs a way back.
Reversibility is part of the design, not an afterthought.
Interested in accountable, continuously improving intelligence?
I welcome conversations with engineering teams, researchers and organisations interested in model orchestration, measurable AI evaluation, agent governance and controlled experimentation.