Build the OS for SMBs.
We are hiring people who have run operations and want to build the system they wish they'd had. Below are the three open roles.
Honest framing.
We are early. The architecture is locked. The first deployments are running. The product is real but young. The work is hard in the way that early-stage operational work is hard: every decision matters, the surface area is wide, and the day-to-day is closer to running a business than working in one.
We work with operators inside our customers' businesses every week. The work is not abstract. You will sit with the people who use the system, watch them work, and rebuild what isn't right. If that sounds tedious, this is the wrong company. If it sounds like the only way to build a real product, we should talk.
The team is small and intentional. We hire slowly. Compensation is competitive but not extraordinary at this stage; equity is meaningful. Remote is fine; we meet in Tel Aviv when the work needs us together.
Three open roles.
Founding Engineer / CTO Track
The work:
You will own the technical architecture end-to-end. The platform is built on a clear set of decisions — local-first, MCP-native, agent-led — and your job is to make those decisions real across new verticals, new integrations, and new capabilities. You will write code, but more importantly you will decide what code other people write.
You will work directly with the CTO on architectural questions and with implementers on deployment-level questions. You will be the technical face of the company in conversations with prospective customers and partners.
Responsibilities:
- Own the architecture of the agent runtime, the MCP layer, and the integration framework.
- Lead the technical design of new verticals as they come online.
- Make the build/buy/integrate decisions for every component the platform depends on.
- Hire and mentor the engineers we add over the next twelve months.
- Be the person the implementers trust when something doesn't work.
You should be:
- Someone who has built operational software in production, at scale, with consequences.
- Comfortable working at the level of system design and at the level of fixing a specific integration that broke at 3am.
- Familiar with LLM-based systems, but not a cargo-culter — you can tell the difference between AI features and AI substance.
- Opinionated about architectural decisions and willing to defend them.
You should not be:
- Someone who wants a defined role with bounded responsibilities.
- Someone who needs a research environment with no pressure to ship.
- Someone who treats AI as a hype layer rather than an engineering substrate.
Senior Implementer
The work:
You will lead deployments. That means sitting with customers — owners, operators, senior coordinators — listening, understanding, and capturing how their business actually works. You will turn what you hear into structured artifacts that the agent can run on. You will be present through the first months of every deployment, and you will own the outcome.
This is the role that most defines whether the company succeeds. The methodology is the product. You are the person who applies it.
Responsibilities:
- Run listening sessions with senior operators in customer businesses.
- Decode transcripts and shared knowledge into MCP files.
- Stand up new verticals end-to-end: from interview to live agent.
- Be present in customer organizations during the transition. Train. Correct. Adapt.
- Refine the methodology based on what works and what doesn't.
You should be:
- Someone who has worked inside operations, not just observed them. You have run a function, owned a P&L, or led a team through change.
- Comfortable in a customer's office, asking obvious questions, taking the time to understand the boring parts.
- Capable of writing — the output of your work is structured documentation that other people execute against.
- Patient. The right way to do this work is slow before it is fast.
You should not be:
- Someone looking for a sales role.
- Someone who wants to build the product instead of deploy it.
- Someone who finds talking to operators tedious.
Operator (Customer-Embedded)
The work:
You will be embedded inside a customer's business during the first weeks of their CORTX deployment. Your job is to make the system work in their specific context — to be the human in the loop until the agent has enough context to run unaided, and to be the bridge between the customer's team and our engineering when things need adjustment.
This is not a support role. It is the operational front line of the deployment.
Responsibilities:
- Spend the first weeks of every new deployment in the customer's office (or remote where appropriate).
- Shadow operators. Use the system alongside them. Surface what doesn't work.
- Translate operational reality back to the implementer and the engineering team in a form they can act on.
- Run training sessions. Build trust. Be the face the customer's team sees.
- Move from one deployment to the next as they go live.
You should be:
- Someone who has done operational work inside a real business. Office manager, operations coordinator, ops lead at a startup.
- Genuinely curious about how other people's work is structured.
- Comfortable being the only CORTX person in the room for weeks at a time.
- Calm in the presence of resistance. Some operators will not want a new system. You will help them get there anyway.
You should not be:
- Someone who needs the comfort of an office team around them every day.
- Someone who finds operational detail tiresome.
- Someone looking for a clear escalation path. You are the escalation path.
What to send.
We do not have an applicant tracking system. We read every email.
Send a note to careers@cortx.systems with:
- A short paragraph about the role you're applying for and why.
- A link to the most relevant thing you've built, written, or run.
- One question you would ask us if we were sitting down for a first conversation.
We respond to every email within seven days. If a role looks right, we move quickly. If it does not, we tell you and we tell you why.