Pick a theme for this site. With reduced motion the background and the logo come to rest. Both can be changed later under Look.
iogentic starts an agent from a verified artifact and runs it in its own sandbox. Where a rule asks for a person, the run waits for a signature. Every step is written to one record.
Concept, November 2026. Nothing on this page is released. The run further down is a simulation with sample data.
An agent passes three products on its way to production. It is written and run in the iogentic harness. Pipesmith, a sub-brand of iogentic, builds, checks and stores it. iogentic runs it and sends the run record back.
The agent is written and run in the harness. It asks before a tool changes anything, and it writes each step of a session as an event.
The pipeline builds the artifact, lists its parts in a bill of materials and scans them for known vulnerabilities.
The tests run and the gate rules are applied. The verdict is signed and bound to the digest of the artifact, so it travels with the artifact.
The registry keeps the artifact and its verdict under one digest. Whoever pulls the digest gets both.
The runtime pulls by digest and checks signature and verdict. It starts the agent only when the verdict is passed, and it writes a record of the run that development can read like a session.
The iogentic harness is the app in which an agent is written and run. It is a native app, written in Rust, with one window. It works with local models and with hosted ones.
In development. The pictures show the app itself, with a demo project and a local model. It is not released.
The release waits until every case passes.
A demo usually shows the good path once. Before a release, the agent has to pass every scenario we collected with you, and it runs them again after every change.
A harness turns an agent into something you can test. We write scenarios from real cases, run the agent against them, keep every trace, score the result against a rubric and fix what fails. The gate stays closed until the score holds.
becomes a scenario
Illustration. One failing case out of 24 keeps the release gate closed. After the fix, that case stays in the set for every later run.
Six functions make up the runtime in this concept.
iogentic pulls an artifact by digest and checks its signed verdict. An agent without a passed verdict does not start.
Each run gets its own workspace. Network access follows an allow-list, and time and resources have limits.
When a rule asks for a person, the run saves its state and waits for the signature. It resumes from the saved state, so a long wait costs no rework.
Every step, tool call and model call is one event on one stream. The stream is the record of the run.
A recorded run can be played against a new version of the agent. The differences show before the new version is adopted.
The model is chosen per step. Local and hosted models sit behind one interface, so the operator decides where the data goes.
This is how a run would look. The agent, the invoice and the supplier are invented. No model is called and nothing is sent.
State: idle
A digital brain for one job in your organisation.
We want to build for mid-sized firms and public bodies in Germany. We start from your forms, your rules and the cases your team handles every week. Then we build the smallest agent that does that one job, and we test it on those cases.
Three things, and they belong together. An agent for one job, an architecture sized to that job, and the harness that makes the agent testable.
An agent for one job in one industry. It knows the forms, the norms and the exceptions, and it stops where a human has to decide.
A narrow scope makes the agent testable. One job has a known set of inputs, a known set of rules and a known person who checks the result.
A single prompt rarely carries a whole workflow. We split the work into an orchestrator, specialist agents, tools and an audit log, and we keep the number of parts as small as the job allows.
We pick the model per task. A large model may plan, a small local model may read out fields, and plain code does the arithmetic.
The scaffolding around the agent: scenarios from real cases, evaluation runs, traces, guards and replay. It is the part that turns a demo into something a team can rely on.
We write the harness before the agent is finished. Its results show when the agent is good enough to put in front of a reviewer.
The point where a human signs is a design decision we make first. Everything in front of it is built so that the signature means something.
Request arrives. A form, a drawing or a mail. The agent records what it was given, for example three files and the form type.
Orchestrator plans. It splits the case into tasks. When something is missing or unclear it asks back, and the question goes into the trace.
Specialists work. Small agents with one skill each check the rule, run the numbers and write the draft. Each may only use the tools and sources declared for it.
Harness checks. Guards block actions outside the scope. The result is scored against the scenarios, and the score goes into the trace.
Human signs. The reviewer reads the draft and the trace with its sources, questions and score. Then they sign, or send it back with a note.
A project has five steps. Each step ends with something your team can look at and judge.
We sit with the people who do the work today. We note where the time goes, which cases are routine and which need a person.
Together we pick real cases, the awkward ones included, and write down what a good result looks like. These become the scenarios.
We build the smallest architecture that handles those cases. Every tool, model and data source is listed before it is used.
The agent runs against all scenarios after every change. You see the score, the traces and the cases that still fail.
Your team runs a pilot and signs off on it. We document how the agent is built, what it may do and how it was tested.
This is how we plan to run our first projects. We will adjust it to what we learn in the interviews.
An illustration of one agent we could build: the completeness check for a building permit application. The case is made up. The steps are the ones we would test.
Case 0142, residential building
The method stays the same, the field is still open. Six fields on the table. None is decided. We score them this autumn and take one or two into customer interviews.
Agents that test and defend AI systems, and the compliance work that EU product rules create for makers of connected devices and software.
AI literacy for companies, and for people who have never used an assistant. Training first, a product later if the demand is there.
Assistants for carers, and products against loneliness for older people. Who pays is the open question.
Agents that buy on behalf of people, and shops that are ready to be found and read by agents.
Cards, maps and small apps generated for one person or one occasion, and thrown away after use.
Agents for planning, permits and public services, where staff are short, the work follows forms, and a human signs at the end. This is where we expect the harness to matter most.
Each founder scores each field on six criteria, alone and before the meeting. Weighted scores decide which one or two go into interviews. The weights are a proposal until the team has changed them once.
Data, model and log can stay in the EU.
You decide per layer where an agent runs. The trace records the choice, so an auditor can check it later.
An agent has four layers, and each one can be placed on its own. We connect to models through OpenAI-compatible interfaces, so the model behind an agent can usually be swapped without rebuilding the agent.
Your systems stay where they are. Inside the EU boundary sit the agent runtime, the model and the trace. For each layer there are three options. The highlighted path shows one possible setup: a data center in Germany, an open-weight model hosted by you, and a log that stays with you.
Illustration of one setup. Which option fits depends on your data, your rules and the task.
Capacity for AI is being built in Germany right now. These are public facts we checked at the source. None of these companies is a partner or customer of ours.
Schwarz Digits, the IT arm of the Schwarz Gruppe, broke ground for a data center in November 2025: 11 billion euros in total, about 200 megawatts at first and room for up to 100,000 GPUs. The first phase is due by the end of 2027, and STACKIT is to run it.
Deutsche Telekom put its Industrial AI Cloud in Munich into operation in February 2026, with nearly 10,000 Nvidia Blackwell GPUs. Telekom operates it, and T-Systems runs the platform.
HammerHAI, one of two German AI factories in the EuroHPC programme, is hosted at HLRS Stuttgart. In March 2026, EuroHPC expected it to start operation in the second half of 2026. It is aimed at startups and small and mid-sized firms, and access is free for eligible European users.
STACKIT and IONOS both offer open-weight models such as Llama 3.3 70B and GPT-OSS 120B through OpenAI-compatible interfaces. STACKIT's model service runs in its region eu01 in Germany. IONOS states that all inference runs in its German data centers and that prompts are not logged or used for training.
Two EU laws, one standard and two sets of security guidance. For each one: what it asks, and what a harness can contribute. This is not legal advice.
The bans and the AI literacy duty apply since 2 February 2025, the rules for general-purpose models since 2 August 2025 and the transparency rules since August 2026. High-risk systems must keep automatic logs (Article 12) and allow effective human oversight (Article 14). For the high-risk uses in Annex III these rules apply from 2 December 2027, after the AI Omnibus moved the date. In Germany the KI-MIG of 22 July 2026 names the Bundesnetzagentur as market surveillance authority.
Every case leaves a trace with its steps, sources and score, and the sign-off records who decided. Guards stop actions outside the scope. Whether a use case is high-risk is a legal question for each case.
Applies since 12 September 2025. Users get access to the data of connected products, and customers of cloud services can switch providers.
We plan to keep scenarios, evaluations and traces in open file formats, so the test record of an agent can move with you.
Requirements for an AI management system in organisations that provide or use AI. Certification is voluntary and done by independent bodies. EN 18286, the first harmonised standard under the AI Act, is designed to sit on top of standards such as ISO/IEC 42001.
Evaluations, traces and the audit log are the kind of operating evidence such a management system asks for. We hold no certificate.
The OWASP Top 10 for LLM Applications 2025 lists prompt injection first and excessive agency sixth. In December 2025 OWASP added a Top 10 for agentic applications. BSI and ANSSI recommend authorisation, input and output limits, sandboxing and monitoring for systems built on LLMs.
In our design, permissions and guards sit in code, outside the model. Each tool gets the smallest permission it needs, actions with an effect outside the agent need a person's approval, and injection attempts are part of the scenario set.
We are not lawyers and we hold no certificate. Whether a use case is high-risk, and what follows from it, is a question for your legal review. The harness supplies the records for that review.
The facts on this page and where we checked them. Checked on 22 and 23 October 2026.
No. We are a founding team in the interview phase. We want to understand the work first and pick one field before we build for customers.
No. We use existing models, including open-weight models that can run on your hardware or with a host in the EU. Our work is the agent around the model and the harness that tests it.
It will be wrong sometimes. A person signs every result, so a wrong draft can be caught before it leaves your team. The failed case becomes a new scenario, and every later version has to pass it.
The design goal is that data goes only where you approved it. Agent runtime, model and log each have options inside the EU, and the trace records which ones a case used.
Compliance depends on the use case and on your organisation, so a product cannot promise it on its own. The harness produces logs, test records and a recorded human sign-off, which are records of the kind the AI Act asks for in high-risk uses. Your legal review decides the rest.
No. You need people who know the work and can tell a good result from a bad one. They help us write the scenarios, and they review the results.
We have no price list yet. We will scope the first projects together with the teams we work with.
Five founders. Profiles follow once each of us has written one, which is slower than building a website.
Between us: software architecture, AI enablement in large organisations, product work, and contacts in energy, utilities and local government. Roles for the evaluation phase: idea owner, market research, customer access, prototyping, and process.
Systems designed for teams that have to run and change them for years.
Bringing AI into large organisations, with training, rules and the people who will work with it every day.
Turning a vague need into something a team can test and decide on.
People in energy, utilities and local government who tell us where their work slows down.
The three products are at different points.
| Product | Role | State |
|---|---|---|
| iogentic harness | Development | In development |
| Pipesmith | Infrastructure | In development QA is a proposal |
| iogentic | Runtime | Concept, no code yet |
Names, the split between the products and the look can still change.
If you run a team where the work follows rules and forms and someone has to sign at the end, we would like to hear what slows you down. Thirty minutes, no slides.