A founder's note

Imagine your next software engineer isn’t human.

It’s an AI agent — with a role, responsibilities, permissions, and a real place on your team.

Now imagine an entire engineering team like that: humans and AI working side by side. Some planning. Some building. Some reviewing. Some approving. Some shipping.

Who does what? Who can approve what? Who is accountable when something goes wrong?

You need a way to actually run that team.

That is why I built SICKR.

A lesson I learned from financial markets

I spent thirteen years at Bloomberg building execution and trading-analytics systems.

On May 6, 2010, the U.S. equity market experienced the Flash Crash. In a matter of minutes, prices moved violently across one of the most technologically sophisticated markets in the world.

What stayed with me was how quickly consequences could compound when systems operated at machine speed.

In the aftermath, I worked on safeguards in execution systems, including a confirmation step before certain large orders could go out. It was a small piece of code. It did not make the system faster. It made someone look before the system acted.

Speed without sufficient controls can amplify consequences just as quickly.

And ultimately, the value of an automated system is not just how fast it can move. It is whether you can trust what it does when you are not watching.

Fifteen years later, AI brought me back to the same problem.

AI gave me leverage. Then it made me the bottleneck.

In late 2025, I started building a product of my own and used AI agents heavily — Codex, Claude, and others. I learned what each was good at and started assigning work almost the way a manager assigns work to engineers.

At first, it felt like extraordinary leverage.

Then the agents started producing more work than I could effectively supervise. I was reviewing outputs, correcting mistakes, restoring context, redirecting work, and checking whether one agent had undone something another had done.

AI had made execution dramatically faster.

But it had not given me a team.

I was still the workflow.
I was still the approval system.
I was still the memory.
I was still the governance layer.

I had not removed myself from the loop. I had simply made the loop much bigger.

That led to the idea behind SICKR:

AI agents don’t just need better prompts. They need a team to belong to.

What if we treated agents like team members?

An engineer does not arrive at a company and receive unrestricted access to everything. They have a role, responsibilities and permissions. They work tickets and follow processes. Someone reviews their work. Some decisions require approval. And when something goes wrong, we can determine who did what.

Why should an AI agent be any different?

I started building SICKR around that idea.

The first time I watched a piece of work go from a one-sentence brief to a merged, reviewed, signed commit without me manually driving every step, I said:

“That’s sick.”

The name stuck.

What SICKR is

SICKR is the operating plane for human-AI software engineering teams.

It lets humans and AI work together like a real engineering organization — with defined roles, responsibilities, workflows, permissions, approvals and accountability.

Your team. Your workflows. Your rules. Define how work should move through support, UX, API, data, platform or whatever engineering teams you operate. Assign roles. Attach skills. Define expectations. Decide what an agent can do automatically, what requires approval, and what it cannot do. SICKR keeps the work on those rails.

Intelligence-neutral. Bring the models and agents you want. Build your own. Replace them as intelligence improves. SICKR is not trying to own the intelligence. It governs how that intelligence participates in the work.

Separation of duties. The actor that performs the work does not need authority to approve its own work. Different agents can plan, implement, review, test and validate. Humans can hold whichever gates matter.

Everything on the record. Every action, decision, approval, failure and dollar is attached to the unit of work as evidence — not buried inside a conversation.

The question changes

How do we assign responsibility?
How do we control authority?
How do we enforce process?
How do we measure cost?
How do we know what happened?
Who is accountable?

Those are organizational problems, not model problems.

They require an operating plane.

That is the layer SICKR is building.

What I am asking

I am not asking you to turn your engineering organization over to autonomous agents. I would not do that either.

I am asking you to treat an AI agent the way you would treat a new member of your team: give it a defined job, clear authority, a workflow, supervision, review and accountability. Then give it real work.

We are looking for a small number of design partners willing to take one real engineering workflow and run it through SICKR from start to finish.

Not a demo workflow.

Your workflow.
Your agents.
Your policies.
Your code.

Let’s find out what happens when AI stops being another tool sitting beside your engineers and starts becoming a governed member of the team.

Humans supervise. AI executes. SICKR runs the team.