Matthew Diakonov, the engineer behind terminator-rs and Mediar's Windows desktop agent.

The shape of his public footprint, in numbers

The shortest way to understand the gap between the bio-line summary and the actual body of work is to look at what is public on GitHub. He has been shipping under the m13v handle since well before Mediar existed; the count and the spread of languages tell you what kind of engineer is on the other end of a Mediar sales call.

Counts pulled from github.com/m13v on the verification date above. Repo count moves; the order of magnitude is the point.

The named projects you can read for yourself

A founder bio is easy to write and hard to verify. Repositories are the opposite. Below are six of his public projects with descriptions pulled from the repos themselves. The first one is the one that matters most for evaluating Mediar; the rest give a sense of the daily output.

The thread that connects them

Almost everything in the list above is some variation on the same idea: get an LLM context from a desktop computer that the LLM did not natively have, then act on it. WhatsApp messages into a model. Browser history into a queryable knowledge base. Screen sessions captured and replayed. Teammate commits summarized so a human reads them in a minute instead of an hour.

The commercial version of that thread is Mediar. A Mediar deployment looks like a Windows host running a Tauri agent, watching a worker do an SAP intake once, and then doing it unattended for the next ten thousand inputs. The accessibility-tree approach (read what the OS exposes, ignore pixels) is the same approach the open-source projects already use; the commercial product just wraps it in audit logs, validation, credit metering, and a no-code workflow editor.

That continuity is why the founder backstory is load-bearing for evaluating the company. The desktop-agent skill set is not something you can hire for in a quarter. You build it across two or three years of throwaway experiments and one or two production rewrites, and you keep publishing the experiments because the next one feeds the last one.

From an open-source recorder to a Fortune 500 production deployment

The arc that ties everything together fits in four hops. The first is the open-source predecessor. The middle two are how that predecessor became a Cargo dependency the commercial product can rely on. The last is what runs unattended on a customer host today.

The hop from Screenpipe to terminator-rs is the most underrated piece. Most companies that start as an open-source project either fold the whole codebase into a closed commercial fork or strip-mine the original repo for talent and let it die. Mediar did the third option: pull the actual execution primitives out into a clean MIT-licensed crate, then make the commercial product a regular consumer of that crate. It is the kind of structural decision that only works if the engineer doing it cares about the code as code, not as a moat.

The stack he actually writes in

Not aspirational. Not a list pulled from a CV. The languages, runtimes, and APIs that show up in his commit history this year, on the company codebase and on personal repos.

How to actually get a real conversation with him

The most honest way to evaluate someone running an early-stage technical company is to talk to them. Mediar is small enough that founder calls are not theater. The turn-key program (priced at $10K, which converts to runtime credits at $0.75 per minute) is structured so that the first serious conversation about a workflow happens directly with the people who will build and ship the automation.

If you came here because you are evaluating Mediar as a vendor, the call below is the right path; if you came here because you are evaluating him for something else, his personal site at m13v.com has direct contact links.

Frequently asked questions