AI Solutions Engineer (Delivery Lead)
for each section heading. Use - for lists. Use
for prose. Remove boilerplate like application instructions? Actually we need to include "How to apply" but remove application instructions? The instruction says: Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. So we should not include "How to apply" section because it's application instructions. So we omit that. Also we should not repeat job title as heading (none given). No Job ID.
We need to preserve all substantive information. So we need to include content from sections except application instructions. Also we need to avoid filler like "commensurate with experience" etc. Not present.
We need to decide which sections to include: "The 30 second version" could be considered About the role? Could be a summary. We'll treat as About the role. Then "Why this role exists". Then "What you will actually do". Then "How you work with CX and Product". Then "The technical work". Then "What we are looking for". Then "Who This Is Wrong For". Then "What you get". Possibly also "Your influence" but that's part of what you will actually do? Already covered.
We need to format lists where appropriate.
Let's extract content.
"The 30 second version": paragraph: "We build governed AI operators, which we call BOBs, that do real work inside small and mid market businesses. Not copilots. Not chat wrappers. Systems with role contracts, budget limits, audit trails, and a human who can see exactly what the system did and why. You will own client deployments end to end, from the first discovery conversation through production and measurement, working alongside a senior CX and Product partner who owns the client relationship. What you learn in each deployment goes back into the platform so the next one starts further ahead."
That's prose.
"Why this role exists": paragraphs: "We are a small team with production clients and a growing pipeline. We are good at the engineering and we are good at the outcomes. What we need now is another person who can hold the whole arc: hear a business problem directly from the operator who has it, design the system that solves it, write the code, put it in production, prove it worked, and then make the platform smarter so the next deployment goes faster than the last. Most engineers can do the middle of that arc. Fewer can do the front of it. Almost nobody does the back of it unless asked. We are hiring for all three. You will also help guide the technical bar for the rest of the engineering team."
That's prose.
"What you will actually do": includes breakdown: Roughly how a month breaks down... bullet list? It's given as ~50% In a repo ... ~25% Client facing ... ~15% On the platform ... ~10% On leadership. Also paragraphs about partner etc. We'll format as
- for each bullet.
Let's extract bullet points:
- ~50% In a repo: You write the code. This is not an architecture role with a hand off to someone else. If you have not shipped production code in the last eighteen months, this is the wrong role.
- ~25% Client facing: Discovery sessions, workflow mapping, design reviews, go live, and the conversation where you show an owner what the system did last week and what it cost. Typically two to three concurrent accounts.
- ~15% On the platform: Turning what you just learned into platform capability: identity and state, tenant scoped memory, playbook construction, tool and action surfaces. Configuration over code forks, every time.
- ~10% On leadership: Everyone here is expected to lead from the front: design review for other engineers, holding the delivery standard, mentoring, and setting the example by doing the work well. Your influence comes from what you ship and how you handle yourself in front of a client, not from a reporting line.
Then paragraphs after: "How you work with CX and Product" is separate section.
But we have separate section "How you work with CX and Product". So we will keep that separate.
Thus "What you will actually do" includes the breakdown and maybe preceding sentence: "Roughly how a month breaks down, so you can decide whether this is the job you want:" then bullet list. We'll include that sentence as prose before list.
Now "How you work with CX and Product": paragraphs: "You have a partner. A seasoned CX and Product leader who owns the client relationship: agenda, cadence, expectations, escalation, follow up, solution design and commercial temperature. That person runs the room. You are in the room. Not on the recording, not reading the readout. For discovery and design review you are present and asking your own questions, because a requirement that reaches you secondhand has already lost the detail that mattered. Yours Technical discovery, the code, deployment, evals, guardrails, instrumentation, and the technical relationship with the client's operator and their technical counterpart. Not yours Renewals, pricing, upsell, invoicing, change order negotiation, quarterly business reviews, and the tier one support queue. You flag commercial risk. You do not carry the quota or the relationship maintenance. We draw this line on purpose. We have seen what happens to engineering throughput when we do not."
We'll format as prose.
"The technical work": paragraphs: "You will design against four primitives. Identity & State Every interaction anchored to objects under strict org level isolation. Memory & Context Tenant scoped transcripts, documents, embeddings, and artifacts in partitioned data planes. Reasoning & Playbooks Model instructions constructed dynamically from each tenant's methodology, ICP, and vocabulary. No fixed framework unless the client asks for one. Actions & Surfaces Tenant specific tools loaded through an orchestrator. Configuration over code forks. Our Production Bar, Which Is Not Negotiable Test coverage that means something: unit, integration, end to end Versioned schema migrations. Nobody touches a production database by hand. Tenant isolation enforced at every layer, verified rather than assumed Secure by default APIs and infrastructure Documentation updated as part of definition of done Every agent action attributable, budgeted, and reversible We optimize for velocity under constraint. Not speed without discipline, and not discipline without shipping."
We can break into paragraphs.
"What we are looking for": includes Required list and Nice to have list. We'll format as
- for each required and nice.
Required bullet points:
- 8+ years building software, including 3+ years shipping and operating production systems you were personally accountable for
- You have shipped LLM powered systems that real users depend on: RAG, structured agents, tool calling workflows, whatever the shape
- Multi tenant architecture experience. Isolation, data partitioning, per tenant configuration, and the failure modes of all three.
- You have built evaluation into an AI system. Offline evals, shadow mode, scoring, regression suites. Not “it looked good in testing.”
- You have built guardrails and rollback paths, and you have used them under pressure
- You can run a technical discovery conversation with a non technical business owner and leave with a design. This is a hard requirement and we test it directly.
- You write clearly. Short, structured, unambiguous. We read your writing before we read your code.
- You have tied a system you built to a number a business cared about, and you can tell us what happened when it moved, or when it did not
Nice to have bullet points:
- Hands on with OpenClaw, the Claude Agent SDK, MCP, or comparable agent runtimes
- Forward deployed, consulting, or small shop background where you were the technical half of the engagement
- SMB or mid market domain depth: field services, healthcare, professional services
- Experience turning delivery patterns into platform capability
"Who This Is Wrong For": paragraphs: "Researchers. We are not doing novel work. We are doing correct work, quickly, for people whose payroll depends on it. Architects who want to specify and delegate. Anyone who needs a written spec before they start. Anyone who wants to work only with technical stakeholders. Our clients run lawn care companies, medical practices, and nonprofits. You will explain retrieval boundaries to someone standing next to a truck."
We'll format as prose maybe with bullet list? Could be list but it's descriptive. We'll keep as paragraphs.
"What you get": paragraphs: "Health coverage through Sedera, paired with Direct Primary Care. Membership based care with a doctor you can actually get on the phone, not a carrier phone tree. Unlimited PTO. Take the time. We care that the work ships and the clients are covered. Real authority over how we deliver, on day one, in writing. You own the delivery engineering standard, you decide how deployments run, and nobody above you is going to relitigate your architecture in a hallway. Surface area you will not get at a larger company. You will touch every layer, talk to every client, and see the direct line from what you built to what the business did."
We'll format as prose.
Now we need to output HTML fragment only, no markdown fences.
We'll produce sections with
headings.
Let's craft.
We'll start with About the role
then
... from 30 second version.
Then
Why this role exists
...
Then
What you will actually do
Roughly how a month breaks down, so you can decide whether this is the job you want:
then - ... etc.
Then
How you work with CX and Product
...
Then
The technical work
... maybe break into multiple
for readability but okay.
Then
What we are looking for
then maybe split Required and Nice to have as subheadings? The instruction says use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings but we should stick to those categories? It says "use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." That suggests we should use those standard headings if applicable. But we can also use other headings? It says use for section headings (e.g. ...). Likely they expect we use those headings for sections we have. We have sections like About the role, Why this role exists (maybe Responsibilities?), What you will actually do (Responsibilities), How you work with CX and Product (maybe Skills?), The technical work (maybe Qualifications?), What we are looking for (Requirements), Who This Is Wrong For (maybe not needed), What you get (Benefits). We could map: About the role -> About the role. Why this role exists -> maybe Responsibilities? But better to keep as given? The instruction says use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings but suggests we should use those standard ones. However the examples are just examples; we can still use other headings as long as they are . Safer to use the given headings: About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. We need to map content to these.
We have:
- About the role: 30 second version summary.
- Responsibilities: What you will actually do (including breakdown)
for prose. Remove boilerplate like application instructions? Actually we need to include "How to apply" but remove application instructions? The instruction says: Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. So we should not include "How to apply" section because it's application instructions. So we omit that. Also we should not repeat job title as heading (none given). No Job ID. We need to preserve all substantive information. So we need to include content from sections except application instructions. Also we need to avoid filler like "commensurate with experience" etc. Not present. We need to decide which sections to include: "The 30 second version" could be considered About the role? Could be a summary. We'll treat as About the role. Then "Why this role exists". Then "What you will actually do". Then "How you work with CX and Product". Then "The technical work". Then "What we are looking for". Then "Who This Is Wrong For". Then "What you get". Possibly also "Your influence" but that's part of what you will actually do? Already covered. We need to format lists where appropriate. Let's extract content. "The 30 second version": paragraph: "We build governed AI operators, which we call BOBs, that do real work inside small and mid market businesses. Not copilots. Not chat wrappers. Systems with role contracts, budget limits, audit trails, and a human who can see exactly what the system did and why. You will own client deployments end to end, from the first discovery conversation through production and measurement, working alongside a senior CX and Product partner who owns the client relationship. What you learn in each deployment goes back into the platform so the next one starts further ahead." That's prose. "Why this role exists": paragraphs: "We are a small team with production clients and a growing pipeline. We are good at the engineering and we are good at the outcomes. What we need now is another person who can hold the whole arc: hear a business problem directly from the operator who has it, design the system that solves it, write the code, put it in production, prove it worked, and then make the platform smarter so the next deployment goes faster than the last. Most engineers can do the middle of that arc. Fewer can do the front of it. Almost nobody does the back of it unless asked. We are hiring for all three. You will also help guide the technical bar for the rest of the engineering team." That's prose. "What you will actually do": includes breakdown: Roughly how a month breaks down... bullet list? It's given as ~50% In a repo ... ~25% Client facing ... ~15% On the platform ... ~10% On leadership. Also paragraphs about partner etc. We'll format as
- for each bullet.
Let's extract bullet points:
- ~50% In a repo: You write the code. This is not an architecture role with a hand off to someone else. If you have not shipped production code in the last eighteen months, this is the wrong role.
- ~25% Client facing: Discovery sessions, workflow mapping, design reviews, go live, and the conversation where you show an owner what the system did last week and what it cost. Typically two to three concurrent accounts.
- ~15% On the platform: Turning what you just learned into platform capability: identity and state, tenant scoped memory, playbook construction, tool and action surfaces. Configuration over code forks, every time.
- ~10% On leadership: Everyone here is expected to lead from the front: design review for other engineers, holding the delivery standard, mentoring, and setting the example by doing the work well. Your influence comes from what you ship and how you handle yourself in front of a client, not from a reporting line.
Then paragraphs after: "How you work with CX and Product" is separate section.
But we have separate section "How you work with CX and Product". So we will keep that separate.
Thus "What you will actually do" includes the breakdown and maybe preceding sentence: "Roughly how a month breaks down, so you can decide whether this is the job you want:" then bullet list. We'll include that sentence as prose before list.
Now "How you work with CX and Product": paragraphs: "You have a partner. A seasoned CX and Product leader who owns the client relationship: agenda, cadence, expectations, escalation, follow up, solution design and commercial temperature. That person runs the room. You are in the room. Not on the recording, not reading the readout. For discovery and design review you are present and asking your own questions, because a requirement that reaches you secondhand has already lost the detail that mattered. Yours Technical discovery, the code, deployment, evals, guardrails, instrumentation, and the technical relationship with the client's operator and their technical counterpart. Not yours Renewals, pricing, upsell, invoicing, change order negotiation, quarterly business reviews, and the tier one support queue. You flag commercial risk. You do not carry the quota or the relationship maintenance. We draw this line on purpose. We have seen what happens to engineering throughput when we do not."
We'll format as prose.
"The technical work": paragraphs: "You will design against four primitives. Identity & State Every interaction anchored to objects under strict org level isolation. Memory & Context Tenant scoped transcripts, documents, embeddings, and artifacts in partitioned data planes. Reasoning & Playbooks Model instructions constructed dynamically from each tenant's methodology, ICP, and vocabulary. No fixed framework unless the client asks for one. Actions & Surfaces Tenant specific tools loaded through an orchestrator. Configuration over code forks. Our Production Bar, Which Is Not Negotiable Test coverage that means something: unit, integration, end to end Versioned schema migrations. Nobody touches a production database by hand. Tenant isolation enforced at every layer, verified rather than assumed Secure by default APIs and infrastructure Documentation updated as part of definition of done Every agent action attributable, budgeted, and reversible We optimize for velocity under constraint. Not speed without discipline, and not discipline without shipping."
We can break into paragraphs.
"What we are looking for": includes Required list and Nice to have list. We'll format as
- for each required and nice.
Required bullet points:
- 8+ years building software, including 3+ years shipping and operating production systems you were personally accountable for
- You have shipped LLM powered systems that real users depend on: RAG, structured agents, tool calling workflows, whatever the shape
- Multi tenant architecture experience. Isolation, data partitioning, per tenant configuration, and the failure modes of all three.
- You have built evaluation into an AI system. Offline evals, shadow mode, scoring, regression suites. Not “it looked good in testing.”
- You have built guardrails and rollback paths, and you have used them under pressure
- You can run a technical discovery conversation with a non technical business owner and leave with a design. This is a hard requirement and we test it directly.
- You write clearly. Short, structured, unambiguous. We read your writing before we read your code.
- You have tied a system you built to a number a business cared about, and you can tell us what happened when it moved, or when it did not
Nice to have bullet points:
- Hands on with OpenClaw, the Claude Agent SDK, MCP, or comparable agent runtimes
- Forward deployed, consulting, or small shop background where you were the technical half of the engagement
- SMB or mid market domain depth: field services, healthcare, professional services
- Experience turning delivery patterns into platform capability
"Who This Is Wrong For": paragraphs: "Researchers. We are not doing novel work. We are doing correct work, quickly, for people whose payroll depends on it. Architects who want to specify and delegate. Anyone who needs a written spec before they start. Anyone who wants to work only with technical stakeholders. Our clients run lawn care companies, medical practices, and nonprofits. You will explain retrieval boundaries to someone standing next to a truck."
We'll format as prose maybe with bullet list? Could be list but it's descriptive. We'll keep as paragraphs.
"What you get": paragraphs: "Health coverage through Sedera, paired with Direct Primary Care. Membership based care with a doctor you can actually get on the phone, not a carrier phone tree. Unlimited PTO. Take the time. We care that the work ships and the clients are covered. Real authority over how we deliver, on day one, in writing. You own the delivery engineering standard, you decide how deployments run, and nobody above you is going to relitigate your architecture in a hallway. Surface area you will not get at a larger company. You will touch every layer, talk to every client, and see the direct line from what you built to what the business did."
We'll format as prose.
Now we need to output HTML fragment only, no markdown fences.
We'll produce sections with
headings. Let's craft. We'll start with
About the role
then... from 30 second version. Then
Why this role exists
... Then
What you will actually do
Roughly how a month breaks down, so you can decide whether this is the job you want:
then- ... etc.
Then
How you work with CX and Product
... Then
The technical work
... maybe break into multiple
for readability but okay. Then
What we are looking for
then maybe split Required and Nice to have as subheadings? The instruction says usefor section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings but we should stick to those categories? It says "use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." That suggests we should use those standard headings if applicable. But we can also use other headings? It says use
for section headings (e.g. ...). Likely they expect we use those headings for sections we have. We have sections like About the role, Why this role exists (maybe Responsibilities?), What you will actually do (Responsibilities), How you work with CX and Product (maybe Skills?), The technical work (maybe Qualifications?), What we are looking for (Requirements), Who This Is Wrong For (maybe not needed), What you get (Benefits). We could map: About the role -> About the role. Why this role exists -> maybe Responsibilities? But better to keep as given? The instruction says use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings but suggests we should use those standard ones. However the examples are just examples; we can still use other headings as long as they are
. Safer to use the given headings: About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. We need to map content to these. We have: - About the role: 30 second version summary. - Responsibilities: What you will actually do (including breakdown)
- ... etc.
Then
- for each required and nice.
Required bullet points:
- 8+ years building software, including 3+ years shipping and operating production systems you were personally accountable for
- You have shipped LLM powered systems that real users depend on: RAG, structured agents, tool calling workflows, whatever the shape
- Multi tenant architecture experience. Isolation, data partitioning, per tenant configuration, and the failure modes of all three.
- You have built evaluation into an AI system. Offline evals, shadow mode, scoring, regression suites. Not “it looked good in testing.”
- You have built guardrails and rollback paths, and you have used them under pressure
- You can run a technical discovery conversation with a non technical business owner and leave with a design. This is a hard requirement and we test it directly.
- You write clearly. Short, structured, unambiguous. We read your writing before we read your code.
- You have tied a system you built to a number a business cared about, and you can tell us what happened when it moved, or when it did not
Nice to have bullet points:
- Hands on with OpenClaw, the Claude Agent SDK, MCP, or comparable agent runtimes
- Forward deployed, consulting, or small shop background where you were the technical half of the engagement
- SMB or mid market domain depth: field services, healthcare, professional services
- Experience turning delivery patterns into platform capability
"Who This Is Wrong For": paragraphs: "Researchers. We are not doing novel work. We are doing correct work, quickly, for people whose payroll depends on it. Architects who want to specify and delegate. Anyone who needs a written spec before they start. Anyone who wants to work only with technical stakeholders. Our clients run lawn care companies, medical practices, and nonprofits. You will explain retrieval boundaries to someone standing next to a truck."
We'll format as prose maybe with bullet list? Could be list but it's descriptive. We'll keep as paragraphs.
"What you get": paragraphs: "Health coverage through Sedera, paired with Direct Primary Care. Membership based care with a doctor you can actually get on the phone, not a carrier phone tree. Unlimited PTO. Take the time. We care that the work ships and the clients are covered. Real authority over how we deliver, on day one, in writing. You own the delivery engineering standard, you decide how deployments run, and nobody above you is going to relitigate your architecture in a hallway. Surface area you will not get at a larger company. You will touch every layer, talk to every client, and see the direct line from what you built to what the business did."
We'll format as prose.
Now we need to output HTML fragment only, no markdown fences.
We'll produce sections with