Jaroslav Pantsjoha
Technical Director | Agentic AI Solution Architect | Google Developer Expert | Author
London, United Kingdom
Actions
I help enterprises move from AI MVPs to production-grade agent systems, and solutions, as a well-governed, secure, repeatable, and at scale.
I'm a Technical Director and Agentic AI Solution Architect at Cognizant, a Google Developer Expert, and a hands-on builder. Over more than 20 years in technology, my work has spanned enterprise operations, cloud-native platforms, consulting and AI delivery.
Having worked through many AI and agentic PoCS, hackathons, and and now all the way to production - I have even written about Building The Agentic Enterprise.
I spend much of my time solving The New Ways of Work, and business disruption ushered by the AI helping enterprises adopt it at scale and define their new moat.
My next book, Harness Engineering for the New Ways of Work - From Solo Expert to AI-Native Team, is out soon, next.
This is where i connects the enterprise operating model with what I've learned hands- on enabled with Harness and Context engineering principles building and maintaining products with AI, and the responsibilities that come with team delivery.
Recognition includes Google Developer Expert membership in 2025 and 2026, and Google Cloud Champion Innovator recognition in 2023/24 and 2024/25.
I contribute to open source and founded the Google Cloud Community of Practice.
Current active certifications:
Professional Cloud Architect, Professional Cloud Developer, Generative AI Leader and Cloud Digital Leader (Google Cloud);
Certified Partner Specialist Gemini Enterprise Deployment (Google Cloud) and
Claude Certified Architect - Foundations (Anthropic).
My five talks connect personal harness engineering, product maintenance, team agents, enterprise transformation and production operations.
Available for London and English-speaking remote events. All Views are my own.
Links
Badges
Area of Expertise
Topics
Practical Harness Engineering for You and Your Team
Everyone in the room has access to the same engine. The model stopped being the thing that limits you some time ago. What limits you now is everything you have and haven't written down around it. That's the harness.
The model doesn't know your intent, your environment or why you're doing any of it. So you codify it: the definition of done, the quality controls, the ways of working, the skills you keep re-explaining. The rule on my team is simple: if it's not in the repo, the agent doesn't know. And codifying it for the agent forced the humans to align first.
I'll open the harness I use to bootstrap every project, the join-the-team plugin, and walk one real change from C4X, an extension I maintain, through the whole release cycle: feature branch, machine and reasoned review, deterministic CI, release, live checks and updates. Then the honest bits: context rot, pull requests you can no longer read line by line, and who remains responsible for support.
Then we turn it up a notch for your team: shared context with a named curator, the AI Squad sized by what one person can stand behind, and the move from developer to delivery orchestrator to business engineer.
Takeaways:
1. Decide the definition of done, the controls and the ways of working, and write them where the agent reads.
2. Gates are deterministic; investigation isn't. CI has no agency. Agents investigate, recommend and open the PR; the writer never approves its own work.
3. Give context an owner, prune on every pivot, size the squad by what one person can stand behind, and stay able to read the architecture.
40 minutes (30 + 10 Q&A); 25-minute cut available. Intermediate. For builders, engineering leads and architects. Delivered 29 September 2026. Part of a five-talk series connecting individual harness engineering, product maintenance, team agents, enterprise transformation and production operations.
We Poisoned Our Own Context: The Human-Alignment Problem in Agentic Delivery
We obsess over whether the model will hallucinate. The failure I actually lived through was quieter and worse.
The model didn't hallucinate.
It got confused, because we had poisoned our own context.
Months of design docs, decisions and reference material piled up in one place, at different dates, some superseding others, none of it curated. The agents, and the people, started giving incoherent answers, and nobody could say why. In a team of five sharing one context bank, that's binary: you operate like an A-Team, or everyone inherits the same rot at once, multiplied.
This talk is the war story and the discipline that came out of it: context as a curated product with an owner and a retention policy, human-to-AI alignment as process we already know (vision / status / roadmap as the interface), and the human overlaps that AI amplifies instead of removing.
The alignment problem was never the model's. It was ours.
Takeaways:
1. Context poisoning ≠ hallucination. Stale, contradictory, uncurated context makes agents confused, and it fails silently until a human says "this doesn't feel right."
2. The same vision / status / roadmap interface that aligns humans aligns agents. You already know how to do this.
3. At team scale the blast radius multiplies. One shared context bank means one team's context debt hits everyone at once. Govern it like a product.
Duration: 30 min (25 + 5 Q&A). Audience: builders, architects, engineering leads. Part 2 of the Build / Secure / Scale signature set.
Solving the Run Phase: The Next Bottleneck for AI Agents
We figured out how to build agents. Anyone can stand up an impressive single-team demo. The run is where it stalls: data that isn't ready, trust and governance left unresolved, integration that costs more than planned, and pilots that never become a live service.
Deployed is not the same as live. Live needs a named business owner, an accountable service owner, access and action boundaries, a support and rollback path, and a way to reassess when models, tools or context change. Those decisions can be named in advance, and that is where the bottleneck now sits: with us.
This session maps the run phase as an operating model. Choose the route first: adopt SaaS, combine it with shared context and controls, or build and resource a platform. Form and name the team that builds and the team that runs. Then run a shared agent platform with a named owner (identity, tool connections, runtime controls, evaluation, telemetry and cost, governed context) so the next squad inherits rather than rebuilds, with a Centre of Excellence feeding improvements back.
You'll leave with three steps to take one working pilot into live service.
Takeaways:
1. Name the business and service owners, with a mandate to act, before the build ends.
2. Agree what live use requires: business evaluation evidence, access controls, support, FinOps and rollback, and a process to reassess after change.
3. Make the next team easier to onboard: a shared platform with a named owner, and a Centre of Excellence that turns recurring needs into supported capabilities.
30 minutes (25 + 5 Q&A). Intermediate. For architects, platform and SRE teams, and engineering leads. Delivered at SREday London, 24 September 2026. Production operations session in the five-talk series.
AI Transformation in Practice: Redefining the Operating Model
How far do you want to take AI in your organisation? Improving a task, redesigning a service and changing how departments work together require different commitments from leadership.
A team proves that AI can make its workflow faster. Then the next improvement needs another department to change a process, share a system or accept a different responsibility. The people who built the pilot may have no mandate to make that decision. This is where I keep seeing a familiar problem: a misalignment of timing and incentives.
Using an illustrative request moving through HR, service operations and finance, I will follow the transition from conventional automation to AI-assisted work and bounded agents. We will examine how domain experts contribute as business engineers, how engineering supports their changes, and who remains accountable for quality and operation. Somewhere between the major systems, there may still be a spreadsheet that everything depends on.
The session connects those delivery decisions to leadership: cultivating capability, maintaining shared context and reusable tools, and making cross-department change worth supporting. As similar AI capabilities become widely available, domain knowledge and the ability to redesign work deserve more attention.
You will leave with a practical way to frame one business change: an outcome to improve, the authority to act, and the conditions for accepting and operating the result.
Takeaways:
1. Match the ambition for AI with the investment and authority needed to deliver the change across its affected owners.
2. Cultivate domain and engineering capability together, with shared context, reusable tools and a supported route into operation.
3. Align incentives with the completed business outcome, including quality, rework and the cost of keeping the service running.
30 minutes (25 + 5 Q&A). Intermediate. For technology and engineering leaders, enterprise architects, transformation sponsors and service owners. Standalone leadership session in the five-talk series.
How I Built It: 12,000 Installs and the Harness Behind Them
I wanted C4 diagrams in Markdown, in my editor, offline. The tools I found didn't do that, so, in the familiar spirit of another weekend project, I built it with an agent. C4X now ships on the VS Code Marketplace and Open VSX and inside Google's Antigravity IDE. Across it and my other extensions, the recorded tally exceeded 12,000 installs on 30 September 2026.
The build was quick. Maintaining what I shipped became the continuing work.
This is the story of what sits around the agent that built it: context with one authoritative home, skills for the work I repeat, deterministic gates, a release that tests the package the user installs, and the harness that became a plugin I now use to start every project. I'll walk one real change through it, share the field notes the install count doesn't tell you, and be honest about the work needed to keep shipping.
Takeaways:
1. Shipping with an agent is fast; maintaining what you shipped is the real work. Plan for it from the first weekend.
2. Give every decision one authoritative home, write skills for the work you repeat, and keep the gate deterministic.
3. An install count measures distribution. Separate it from adoption, and read the rejection before you count the activity.
30 minutes (25 + 5 Q&A). Intermediate. For builders, GDG/DevFest and AI-engineering meetups. A prepared case-study session; final screenshots and rehearsal are in progress. Install totals are a dated distribution measure, not a count of active users.
The Right Agent Is All You Need
Which agent, for which work, owned by whom? Once individuals are productive with their own assistants, teams need to decide what to share and who will maintain it.
Enabling agents is a business process first. Keeping knowledge curated, up to date, and owned is what makes the workflow dependable. The moment an agent or workflow has no owner, it can go out of date and lose the team's trust. Having the tools doesn't make the organisation successful.
This session works through private agents, shared knowledge and skills, and team agents. It uses the four team-agent archetypes discussed by Nufar Gaspar on the AI Daily Brief, with credit to that source; I call the bridge archetype a workflow agent to keep attention on the process it serves. Examples from my own harness and C4X connect these choices to maintained context, access boundaries and accountable ownership.
The focus is the work itself: what people need to agree, which knowledge must stay current, and who can authorise a change. It connects practical harness engineering to the wider enterprise transformation discussion.
Takeaways:
1. Decide whether the work needs a private agent, shared knowledge and skills, or a team agent.
2. Choose the agent around a defined workflow and its access requirements.
3. Name an accountable owner for the process and its knowledge, with a way to review changes and keep it current.
30 minutes (25 + 5 Q&A). For engineering leads, architects, product and process owners, and transformation teams. Mixed technical and business audience. Prepared session; demo and rehearsal preparation remain in progress.
Jaroslav Pantsjoha
Technical Director | Agentic AI Solution Architect | Google Developer Expert | Author
London, United Kingdom
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top