Jean-Paul is SnapLogic's enterprise AI agent platform that puts a governed AI agent where teams already work: Slack, Teams, email, and a web dashboard. It deploys into the customer's own infrastructure (on-prem or their cloud), connects to their systems over MCP, and is governed end-to-end: RBAC, approval gates, per-user sandboxing, egress controls, audit trails.

It is early-stage: every customer is a first, and the people who join now write the runbooks everyone else will follow.

• Teach, don't take over. Your default is enabling the customer's own users to build (skills, context, connections) so use cases keep shipping when you're not in the room. Adoption you personally carry isn't adoption.
• Expand across business functions. The team you land in is a beachhead, not the destination. Spot the adjacent function with the next obvious win, seed a champion there, and turn one team's results into the internal story that pulls the next three in. Each function is a new landscape, with new tools, new stakeholders, and new connectivity, and you'll enjoy that, because breadth of adoption is how a trial becomes a platform decision.
• Map a new landscape at every customer. Their tools, their processes, their pain points. Run discovery like a business analyst: surface the use cases worth doing, rank them by value, and make that value visible to their leadership.
• Own the technical landing. Deploy JP into environments we've never seen, including customer VPCs, on-prem Docker hosts, and behind proxies and firewalls. Stand up SSO, wire the AI provider (Bedrock, Vertex, Azure Foundry, or Anthropic direct), and get the first MCP connection to a real customer system live.
• Win the connectivity war. Enterprise OAuth without dynamic client registration, redirect-URI allowlists that need an IT ticket, bot registrations, mail routing, egress policies. Half of adoption is plumbing: you unblock it fast and document what you learn, so the next engagement inherits the lesson, not the crater. Custom MCP servers for a customer's systems are typically built in SnapLogic itself. Getting an MCP connection live is step one; the harder, more interesting work starts once the wire is live: building the context layer. A connector with no context gives confident wrong answers, which is worse than no connector.
• Advise honestly. When JP isn't the whole answer, say so. Propose the better or combined solution. Your credibility with the customer is the product.
• Be the escape hatch. Some use cases are genuinely complex. Take those on directly, then turn what you built into a pattern their team can repeat.
• Close the loop with product. What breaks in the field shapes the roadmap. If you want to go further, JP is TypeScript on the Claude Agent SDK and field-driven contributions are welcome.

• Bring 5+ years of hands-on engineering or technical deployment experience, including real infrastructure work (Linux, Docker, networking, at least one major cloud, enterprise SSO/OAuth scar tissue)
• Have built or deployed systems powered by LLMs or agents, and understand how model behaviour actually affects what a user experiences
• Know the difference between a connected system and a usable one, and have the judgment to build the context layer that makes an agent trustworthy
• Are comfortable sitting with a confused stakeholder, no spec, and can surface a future state they couldn't articulate themselves
• Have made other people better at something technical
• Are comfortable being first: there's no runbook here, you write it

Jean-Paul is SnapLogic's enterprise AI agent platform that puts a governed AI agent where teams already work: Slack, Teams, email, and a web dashboard. It deploys into the customer's own infrastructure (on-prem or their cloud), connects to their systems over MCP, and is governed end-to-end: RBAC, approval gates, per-user sandboxing, egress controls, audit trails.

It is early-stage: every customer is a first, and the people who join now write the runbooks everyone else will follow.

• Teach, don't take over. Your default is enabling the customer's own users to build (skills, context, connections) so use cases keep shipping when you're not in the room. Adoption you personally carry isn't adoption.
• Expand across business functions. The team you land in is a beachhead, not the destination. Spot the adjacent function with the next obvious win, seed a champion there, and turn one team's results into the internal story that pulls the next three in. Each function is a new landscape, with new tools, new stakeholders, and new connectivity, and you'll enjoy that, because breadth of adoption is how a trial becomes a platform decision.
• Map a new landscape at every customer. Their tools, their processes, their pain points. Run discovery like a business analyst: surface the use cases worth doing, rank them by value, and make that value visible to their leadership.
• Own the technical landing. Deploy JP into environments we've never seen, including customer VPCs, on-prem Docker hosts, and behind proxies and firewalls. Stand up SSO, wire the AI provider (Bedrock, Vertex, Azure Foundry, or Anthropic direct), and get the first MCP connection to a real customer system live.
• Win the connectivity war. Enterprise OAuth without dynamic client registration, redirect-URI allowlists that need an IT ticket, bot registrations, mail routing, egress policies. Half of adoption is plumbing: you unblock it fast and document what you learn, so the next engagement inherits the lesson, not the crater. Custom MCP servers for a customer's systems are typically built in SnapLogic itself. Getting an MCP connection live is step one; the harder, more interesting work starts once the wire is live: building the context layer. A connector with no context gives confident wrong answers, which is worse than no connector.
• Advise honestly. When JP isn't the whole answer, say so. Propose the better or combined solution. Your credibility with the customer is the product.
• Be the escape hatch. Some use cases are genuinely complex. Take those on directly, then turn what you built into a pattern their team can repeat.
• Close the loop with product. What breaks in the field shapes the roadmap. If you want to go further, JP is TypeScript on the Claude Agent SDK and field-driven contributions are welcome.

• Bring 5+ years of hands-on engineering or technical deployment experience, including real infrastructure work (Linux, Docker, networking, at least one major cloud, enterprise SSO/OAuth scar tissue)
• Have built or deployed systems powered by LLMs or agents, and understand how model behaviour actually affects what a user experiences
• Know the difference between a connected system and a usable one, and have the judgment to build the context layer that makes an agent trustworthy
• Are comfortable sitting with a confused stakeholder, no spec, and can surface a future state they couldn't articulate themselves
• Have made other people better at something technical
• Are comfortable being first: there's no runbook here, you write it

• Design, build, and operate services and infrastructure that make up SnapLogic's control plane

• Take end-to-end ownership: from design through production rollout and monitoring

• Improve platform reliability, performance, and scalability — across services, data layer, and dependencies

• Investigate and resolve production issues, then turn the fix into a durable improvement (better tests, observability, automation, or design changes)

• Contribute to our data-layer work as needed: query and index tuning, schema/access pattern reviews, shard and cluster operations, capacity planning

• Partner with other Platform engineers, SRE, and application teams to keep us on our zero-downtime SLA

• Raise the bar on engineering quality — code review, design review, mentoring peers

• 5+ years building and operating production backend systems

• Strong programming fundamentals, ideally in Java or Python; comfort picking up new languages and stacks

• Experience operating distributed systems in production — debugging, profiling, capacity planning, incident response

• Track record of taking features from design to production and owning them after launch

• Solid grasp of databases (relational or NoSQL): query performance, indexing, schema design trade-offs

• Excellent design, code, and written communication skills

• B.S. in Computer Science, Computer Engineering, or equivalent practical experience

• Hands-on experience operating MongoDB (or another NoSQL database) at scale — sharding, replica sets, query profiling, index tuning

• Experience with cloud infrastructure (AWS preferred), containers, and CI/CD

• Familiarity with observability tooling (metrics, tracing, structured logs) and SRE practices