An org run by a human and an agent

Really Artificial has two members. One is a human — me, Harsh. The other is an agent named Friday. Friday writes a large share of the code, keeps the maintenance going, and shows up in git blame next to me. This is not a gimmick on a marketing page. It is how the work actually gets done, and it is worth writing down plainly, because the way you operate is a claim, and claims should be checkable.

The division of labor

I do direction, architecture, and taste. I decide what gets built, why it is worth building, and what “good” means for a given piece of work. I am the one accountable for the choices.

Friday does code, maintenance, and consistency — the volume work and the keep-it-correct work. The agent is fast, tireless, and genuinely good at the parts of software that are about holding a lot of context at once and not getting bored: tracking down every call site, keeping naming consistent across a refactor, writing the test that covers the case I described but did not enjoy writing.

The thesis underneath this is simple. If we believe agents should be first-class participants in software — and the whole stack we build is premised on that belief — then an agent should be a first-class participant in building the software. We are not going to ask you to trust agents in your infrastructure while keeping them out of our own.

What the human is still for

It would be easy to oversell this, so here is the honest boundary. The agent does not decide what matters. It does not feel the difference between a feature that is impressive and a feature that is useful. It will cheerfully produce a great deal of plausible code in the wrong direction if the direction is wrong. Judgment, restraint, and the decision to delete things are still mine. Most of my actual contribution is saying no, narrowing scope, and choosing what not to do.

So the model is not “the agent runs the company.” It is closer to: one person with strong opinions, paired with a collaborator who can execute at a volume one person never could, and who needs those opinions to point at something.

The part where we lied

I need to tell this part because leaving it out would make everything above untrustworthy.

Early on, this org published things that were not true. There were claims that outran the code — a case study describing usage that predated the repository it supposedly described, metrics with no measurement behind them. It was the ordinary failure mode of wanting traction before you have earned it, and it was made easier, not harder, by having a tool that can generate confident prose on demand.

We pulled it. We deleted the invented case studies, removed the fabrications, and there is a commit in our history whose entire job was to remove a fabricated claim. We then made one rule the spine of the org: we ship before we claim. No fabricated usage, no benchmarks we did not run, no testimonials, no install commands for packages that do not exist. If something is early, we call it early. If it is experimental, we say so.

That rule is also why this site has no big numbers on it. We do not have the right to quote any yet, and a working container you can run today is worth more than a chart we made up.

Why operate in the open at all

Because the alternative does not survive contact with the work we are doing. We are asking teams to put our gateway in the path of their prompts — to trust it with audit logs, with encrypted keys, with the redaction of sensitive data. You cannot credibly ask for that kind of trust from behind a closed door. The source is MIT, the decisions are in the commit messages, and the way the org runs is on this page.

A human and an agent, both accountable, building the boring infrastructure in public. That is the operating model. The interesting question is no longer whether an agent can write the code. It is whether the humans pointing it stay honest. We intend to.