An engineering center for hard problems
We solve hard problems: AI, mathematics, engineering.
Bring us the problem, not a finished spec. We look at the process and what it costs, then pick the method: AI, an algorithm, an ERP system or a mix. We use AI where it pays for itself, and if it won’t, you’ll hear that from us before any work starts.
You describe the problem in your own words; we answer with what we’ve already built
These are real problems people have brought us. Each one has a case study behind it: the industry, what we built and what we could measure.
Five kinds of problem and one rule: the problem first, the technology second
When an off-the-shelf tool can’t solve it, we go deeper
Automation takes an existing tool and wires it into the process. Some problems won’t give way to that: they need an algorithm of their own, numerical methods with controlled precision, or research. For those we have a technology base of our own: libraries and engines we write and maintain ourselves.
Our own numerical base
Balansis is an open numerical library in which loss of precision is visible and can be checked.
In ordinary arithmetic the sum [1e16, 1, −1e16] comes out as 0; Balansis keeps the remainder of 1.0. The library’s case study walks through it.
A metric instead of “seems to work”
Every model is compared against a simple baseline. If it doesn’t beat the baseline, you don’t need it.
We publish negative results. The open Agent Native Universe repository, for example, records that on single-agent tasks the relationship graph between agents gave no advantage.
Reproducibility as an engineering norm
We build research systems to be deterministic: the same input gives the same result, byte for byte. That way a result can be checked and a bug can be reproduced.
That is how our agent runtime, Agent Native Universe, works: anyone who downloads the code can replay a run from its log.
From problem statement to a working system
We cover the whole path: framing, research, prototype, a system in operation. When ready-made libraries and algorithms don’t fit, we write our own.
Example: aircraft parts procurement. From an AI agent on the work mailbox to a prototype procurement system with 11 screens and 6 roles.
What we built, and what we could measure
Contracted pilots, systems in operation and prototypes tested on real data. We don’t name clients: each case gives the industry, the task and figures with a note on where they come from.
Open code, proofs and runs that repeat
Here’s what you can open and check yourself. Where the code is closed, we show how the system behaves.
The workshop: where we test our methods
Before we offer a method to a client, we try it on these systems. Each card carries its status on the same scale as the technology page: in production, in active development or research.
StudyNinja
in productionLearning platform
The platform our methods run on
A study platform for school students: a school mathematics knowledge graph, gap diagnostics and the choice of the next learning step. It runs in production, so far as a closed beta.
studyninja.ruKnowledgeBaseAI
in active developmentKnowledge platform
A knowledge graph as a separate layer of the system
An engine that describes a domain as a connected model: entities, relations and where each piece of knowledge came from. It runs as a separate service; in production it runs the StudyNinja graph.
Agent Native Universe
in active developmentAgent runtime, open source
An environment where agents negotiate, pay and reach agreement
A runtime for self-organising agents: relationship negotiation, a resource economy, a PBFT-style agreement protocol for a fixed set of nodes and nested groups of agents. The rules are enforced by code, not by a request in a prompt.
research programmeMagicBrain
researchNeural core
Our own research line in brain-like networks
A research core: spiking networks, local learning, and a network architecture set by a compact genome instead of being designed by hand. The code is open; it is not used in products yet.
Balansis
in active developmentNumerical library
Arithmetic that holds where ordinary arithmetic breaks
A computation library in which division by zero, overflow and loss of precision do not take the calculation down and stay visible in the result. The code is open.
UWT
researchResearch track
Theoretical work with a monograph and a prepared preprint
A separate research line: a monograph, an experiment registry with tests and a preprint package that is prepared but not yet submitted. Each experiment is labelled with how far its result can be trusted.
uwt.xteam.proUnderstand first, then build: eight steps from problem to result
- 01
Talking through the problem
We pin the problem down in plain terms: where the gain is, where the data is, where the limits are.
- 02
Data and process check
We check whether the data exists and whether it carries a signal. The check ends with an answer on whether a solution can be built on this data, before the pilot and before the main spend.
- 03
Choosing the method
The technology comes last: AI, an algorithm, an ERP system or a mix. We pick whatever gets to the result more cheaply.
- 04
Architecture and hypothesis
We design the whole system (models, interfaces, failure scenarios) and state a hypothesis that can be disproved. The success metric is agreed before we start.
- 05
A pilot on a real part of the process
A working system on a limited part of the process, with a metric and a comparison against how things were before.
- 06
Quality checks
Quality evaluation, load tests and security checks. We look for the weak spots before your users find them.
- 07
Operation and integration
We wire it into your working systems: 1C, CRM, ERP, messengers. Access rights, an action log and the running cost are set up from the start.
- 08
Result and next steps
We judge the result by the metric agreed before the start, then hand the system to your team with documentation and training so they can run it without us. If it makes sense, we move on to neighbouring processes.
A small team of engineers and researchers
Why we are called The Eighth Day Team
The story of creation fits into seven days. There is no eighth day in it, and we read that as an invitation: the world is given, and what comes next is human work. To understand how things are made, to build what was not there before, and to answer for the result. That is how we work: we take on problems that have no ready answer and see the solution through until it works.
We used to be known as XTeam.Pro. The name has changed; the team, the approach and the legal entity (IKSTIM.PRO LLC) have not.
The people who build our own systems
Your project is run by the engineers who build and maintain our knowledge graph engine, open libraries and agent runtime.
Figures with a source
Our figures are checked against project artefacts: the contract, tests, configuration. Where there is no confirmation, the case says so, and estimates are labelled as estimates.
Safety first
We design rollback, an action log and pre-release checks together with the system, so changes can ship often and without heroics.
People answer for the result
AI agents do the routine part of our engineering work, within limits we set. Decisions, acceptance and signing off the result stay with people.
Industries of our client projects
Our case studies are anonymised: each one names the industry instead of the client.
What you can check
A measured result
Panel specifications from CAD drawings: preparing one takes 10–30 seconds instead of 2–15 hours by hand, and the output matched the manual specification line by line.
See the caseOpen code
The Balansis numerical library on PyPI (1.1.0, AGPL-3.0 or a commercial licence) and the Agent Native Universe agent runtime under MIT. You can download the code and check it.
Balansis on PyPI Agent Native Universe on GitHubFormal proofs
The algebra of the Balansis model is proved in Lean 4 with no gaps (the model over the reals, not float64).
See BalansisHow we work
We agree the success metric before we start and accept the result against it. Agent actions with costly consequences need a person to confirm them.
See how we workContracts are signed by IKSTIM.PRO LLC. Legal details
We write about what we build ourselves
Notes from practice: where document search systems break, when several agents do worse than one, how to work out payback before a project starts. No trend round-ups.
Tell us what you are dealing with.
Describe the problem in your own words. We’ll come back with how we’d solve it and what it should give you in numbers, or tell you plainly that it isn’t worth doing.
Not ready to write? Work it out yourself in the AVA calculator: what the process costs you now and what budget for automating it would pay back. Your figures, no form, no price from us.
Estimate the payback