knyta /ˈknŷːta/ verb, Swedish — to tie; to knot; to bind together.
Knyta turns the CSVs and exports other people send you into clean rows in your database. Every file runs through pipeline code you can read, replay and trust. When a sender changes their format, Knyta rewrites the pipeline. Nothing lands in your database until it's approved. Nobody fixes a script at midnight.
We set it up with you. You build nothing, maintain nothing, and sign off as much or as little as you want.
The problem
Every file someone sends you was made in a hurry, on somebody's Tuesday evening. Your work runs on data other people produce. It arrives as whatever their system happened to export: headers on line four, decimal commas, three date formats in one column, a TOTAL row at the bottom. Generic ETL tools assume clean input. Reality doesn't, so someone cleans it by hand. Usually you.
;;Kundrapport,,
Genererad:,12/1/2026,,
,,,
ORDER NO,customer,Amount ,date
10 234,Acme AB,"1 024,50",2026-01-12
10235,acme ab,980.00,12/01/2026
10236,Beta GmbH,,13.1.2026
TOTAL,,"2 004,50", order_no │ customer_id │ amount │ ordered_at
──────────┼─────────────┼─────────┼──────────
10234 │ cus_8f3a │ 1024.50 │ 2026-01-12
10235 │ cus_8f3a │ 980.00 │ 2026-01-12
10236 │ cus_91bb │ flagged │ 2026-01-13The header noise and the TOTAL row were read as furniture and dropped. The space-grouped numbers and decimal commas were parsed, the three date formats reconciled. The missing amount was flagged for review, not guessed.
Who it's for
It shows up in more places than you'd expect. A founder whose product runs on customer uploads. A recruiter reconciling candidate lists that arrive in a different shape from every client. An analyst whose month starts with the same spreadsheet and the same twenty minutes of cleanup.
Different jobs, the same problem: the data is someone else's to format and yours to deal with. If that's a standing item in your week, Knyta is for you — whatever your title.
Destinations are pluggable by design. Each one declares what it can do, and the engine delivers to it with the same transactional care. Postgres works today; APIs and other databases are on the way.
How it works
Most "AI-powered" tools put a model in the hot path and hope. Knyta doesn't. AI does the one thing it's genuinely good at — reading a messy file nobody has seen before and writing the code to handle it. It does the same when a sender's format drifts, so the pipelines maintain themselves. Everything else is pinned, replayable and audited.
An intake channel is a private address that belongs to one sender. We set it up. They send the file there, the way they have always sent it, and you stop being the person who forwards attachments.
Knyta recognises a file it has handled before and runs the pipeline you already approved for it: same file in, same rows out. It also checks that the values still look the way they should. If two columns quietly swapped meaning behind unchanged headers, the file parks for a human instead of landing wrong.
An AI agent reads the actual file and writes readable pipeline code for it. The agent then tests that code against the file, through the same path a real run takes. All of this happens in a sandbox with no credentials and no network.
A new pipeline writes to a stand-in that cannot write anything, by construction. You see the rows it would have delivered before any of them are real. How often you sign off is a setting: every ingest, only new and changed pipelines, or hand the checks to us.
You never get half a file. One that fails validation is held whole. If a step of a delivery fails, Knyta undoes the steps before it. If the outcome cannot be known, the file waits for you with its full history. (Deliveries run as a saga: retried when that is provably safe, rolled back in reverse order, quarantined when the result is unknowable.)
Principles
Data ingestion fails in quiet, expensive ways. Four rules hold up everything we build.
Every pipeline is plain, readable code with an explicit validation contract. It can be opened, diffed and read line by line. No model decides what happens to your columns at run time, and no logic hides behind an API nobody can inspect.
The clever part happens before approval, never during a production run. That is what gives you a result you can reproduce and a failure you can explain.
Autonomy is granted per decision type, lifted slowly after clean track records, and revoked the instant something faults. The riskiest actions keep a human in the loop for good. Every gate decision lands in an append-only audit log.
Silent success is the expensive failure. A wrong number that passes costs far more than an import that stops and says why. So Knyta stops and says why.
Contact
We work hands-on with a handful of early users right now. Send the ugliest file you deal with, and we'll tell you straight whether we can tie it down. You get an answer within two working days, and if it's a fit, we do the setup with you.
Your file stays between us. We use it to answer your question and nothing else, we never pass it on, and we delete it whenever you ask. If an NDA makes this easier, say so and we'll sign one first.
hello@knyta.net