← Back to Blog

Open Source Companies in the Post-Agent World

Common Practice

there’s something in our repos that probably shouldn’t be there. it’s either an amazing experiment, completely useless, or a real threat to our business.

in the past, open source meant open sourcing your code. people could run it, modify it, redistribute it. later, with things like 3d printers, code even took physical form.

but a company is not just code.

a company is the processes it runs. how decisions are made. how work actually happens. who the users are. how gtm works. how things get prioritized. what gets ignored.

and none of that was really open source.

those things lived in meetings. in people’s heads. sometimes in a blog post. mostly nowhere. and that wasn’t an accident - there wasn’t much upside in sharing how your company actually works.

open source never really captured the underlying processes inside a company. sure, you’d share a code of conduct or instructions to replicate a dev environment.

but not how decisions are made day to day. not how ambiguity gets resolved. not what “good” actually means.

and when i say process, i don’t mean workflows. i don’t mean zapier. i don’t mean connecting two saas tools.

i mean the judgments a company makes repeatedly: how it qualifies leads. how it answers certain emails. what it pays attention to. what it deliberately ignores.

now you’re thinking “this isn’t new, we have notion for this.” yeah. and i’m sure everyone loves reading those docs. let’s be honest: most of that stuff is dead on arrival.

agents change the equation.

i’m using “agents” in a specific sense here. agentic coding tools like cursor, opencode, or the claude cli let you define rules or agents in plain text. you can scope them at the user level, or more interestingly, at the repo level.

that means you can codify decision logic in a form that actually runs.

just like infrastructure as code, you can now treat process as agents. how work gets done. how decisions are made. how systems get updated. written down, versioned, and living next to the code.

you can write down your icp. encode how outreach should work given your current strategy. explain how you reply to users. what matters. what doesn’t.

and put all of that in the repo.

right now, if you (the human) disappear, a lot of small but important things vanish with you. how you qualify leads. how you respond to edge cases. what “good enough” looks like.

with agents, you don’t write a doc that explains what to do. you write something that does the thing.

for me, an agent is closer to code than documentation. it lives in the repo. you run it when you need it. it can act. write messages. update a crm. edit notion pages. change state.

and because it runs, it gets exercised.

docs don’t get exercised. that’s why they rot.

one side effect is that you’re forced to be explicit. if an agent writes a bad message, it’s usually because you didn’t specify something. you didn’t have a clear opinion. you didn’t write the judgment down.

instead of clarity living in your head for one interaction, it lives in the agent. and the agent stays.

a message you send is gone forever. the company never benefits from the thinking that went into it.

an agent prompt sticks around. you improve it. the next output is better. that compounds.

once process works like this, it starts looking a lot less like documentation and a lot more like code.

and that’s where the open source question shows up.

why wouldn’t you open source your company agents the same way you open source the rest of your codebase?

once process lives in the repo and actually runs, it’s no longer “some insight in a founder’s head.” it’s just another thing that executes.

people can see how the company operates. they can run it. change it. see what breaks.

instead of process dying in meetings or notion pages, it gets exercised. and once it gets exercised, it can improve.

maybe that’s an amazing experiment.

maybe it’s useless.

or maybe it’s dangerous.

i don’t know yet.

© 2026
B.SHAFII