[RADAR 11x] Lightning Sessions: AI-Proof Your Career

Summary

Five AI leaders took the stage for six minutes each to answer the question posed by the session's title: what does it take to AI-proof your career?

Eric Siegel, CEO of a predictive AI company and author of The AI Playbook, argued that generative AI's unreliability is exactly where predictive AI earns its keep, by flagging the small share of high-risk cases that need a human review before a system ships. Maddy Zhang, a senior software engineer and content creator, walked through the automations she runs daily, from a morning briefing pulled from her calendar and inbox to an email triage system that drafts replies but never sends them without her approval. Mik Kersten, author of Project to Product and the newly released Output to Outcome, shared data from more than 3,600 organizations suggesting only 8% of a typical knowledge worker's time produces anything of value, and argued the real career risk is working inside an operating model built for a slower era. Maya Gonimah, CTO of the AI orchestration platform Thread AI, laid out a framework for deploying agents safely in the enterprise, built on control, governance, and reliability. Craig McLuckie, co-creator of Kubernetes and now CEO of Stacklok, closed with a case for building an open, inspectable "harness" around agents instead of relying on gateways and kill switches after something goes wrong.

Key Takeaways

• Predictive AI can act as a reliability layer for generative AI, routing the riskiest cases to a human reviewer so an otherwise unreliable system becomes safe enough to deploy.
• Only 22% of data scientists say their new AI initiatives usually reach deployment, according to Siegel, which means most finished models never reach production.
• Email automation works best as a draft generator, not an autonomous sender. Zhang keeps a human in the loop on every message her AI agent prepares.
• In the organizations Kersten studied, only about 8% of end-to-end knowledge work time was genuinely productive, with the rest consumed by approvals, waiting, and coordination that agents are now positioned to absorb.
• Enterprises deploying agents need three things in place before launch: scoped access control, an audit trail that can explain every decision, and a plan for what happens when a multistep process fails partway through.
• Craig McLuckie argues enterprises should "own the harness, rent the models," rather than treating a single AI vendor's agent framework as a permanent foundation.
• Quantitative skills, critical thinking, and the ability to debug a system remain the most durable career assets as agents absorb more routine work.

Deep Dives

Predictive AI and generative AI: pairing reliability with reach

Eric Siegel, CEO of a company that helps enterprises deploy predictive AI and author of Predictive Analytics and The AI Playbook, opened with a practical case for pairing generative and predictive systems rather than picking one. His argument starts with a number: "only 22% of data scientists say their new initiatives usually deploy." Most predictive AI projects that get built never reach production, and Siegel sees the same pattern playing out with generative AI.

His fix is routing risk to a human. Take a consumer-facing chatbot that performs well on its own, say 95% of the time. That sounds strong until you weigh what happens the other 5% of the time: a hallucination, a wrong answer, a disclosure that shouldn't happen. Siegel said that error rate "could easily be enough of a problem to make the whole system not viable, can't be deployed, won't realize any value." His solution is to use a predictive model to flag the roughly 20% of interactions most likely to go wrong and route only those to a human reviewer. Net error rate drops to around 1%, "and suddenly you can deploy."

He pointed to Twilio funneling flagged customer service emails to reviewers before they go out, and NextGen Healthcare predicting which insurance claims are likely to be denied before submission, as examples already running in production. Siegel told attendees not to "be satisfied with being just excited about the rocket science, get the rocket launched," and argued most organizations should be putting at least as much investment into predictive AI as they do into generative AI.

Asked what this means for someone starting a career now, Siegel's answer was direct: "I don't think quantitative skills, and the need for them in humans, is going anywhere." His view is that picking the right metric, profit and savings for predictive systems, real performance in the intended use case for generative ones, separates a project that ships from one that doesn't. That judgment call, he argued, still needs a person.

Running a life and a career on scheduled AI tasks

Maddy Zhang, a senior software engineer at a large tech company and a content creator with an audience of roughly 250,000 across YouTube, Instagram, and LinkedIn, walked through the recurring AI tasks she has built into her daily routine using scheduled prompts, work she said applies to "any AI of your choice," not one specific tool or model.

The first is a daily morning brief that pulls from her calendar, Gmail, and Slack to generate a plan for the day, including time zones when she's traveling for a talk. "I like it because it clearly states exactly what I need to get done," she said, describing how the task sorts her priorities before she's opened her laptop.

The second is an email triage agent that reads her personal inbox and decides what needs a response. Zhang said it gets "maybe 70% of everything I actually need to respond to," catching brand outreach worth a reply and skipping newsletters that don't need one. She doesn't let it send anything on its own, though: "I personally choose to not have my AI agent send the email itself. I just make sure that they exist as drafts, and then I go in and tweak anything, and then send it." She also had to coach the system to sound like her, since early drafts read, in her words, more "AI-y" than she wanted.

A third use case was lighter but telling: handing the agent a recipe and letting it order the ingredients from her grocery delivery service while she was on a phone call, never touching her laptop. It over-ordered eggs once and nothing else. The fourth is a Slack update that tracks the production status of her videos and flags the top priority task for her and her team each day.

None of these are technically complex, which was Zhang's point: "these are just very simple use cases, but you can do so much with scheduled tasks and AI." Her message to the audience was to apply that same pattern to cut through their own daily backlog.

Why most knowledge work still isn't productive

Mik Kersten, founder of a software delivery company and author of Project to Product and the newly released Output to Outcome, framed the AI moment as a repeat of a pattern he's seen before. New technology doesn't just change tools; it eventually rewires the organizations around it, and the rewiring is where careers rise or fall.

He opened with a story about early twentieth-century car factories. When electricity replaced the steam engine, some manufacturers simply swapped the central engine and kept the old layout; Ford tore out the central drive system and decentralized machinery across the line instead. The first approach didn't survive. "If you had a career in helping those belt drives and servicing steam engines, that was no longer a great career," Kersten said. "Whereas if your career was around scaling mass production, well, that was a great career."

Kersten argued AI is creating the same split today, between AI-native organizations with operating models built around agents, and legacy organizations applying the technology without changing how work actually flows. Drawing on data from more than 3,600 organizations, he said "the actual productive part of the knowledge work... was only 8% of the end-to-end time," with the rest consumed by approvals, waiting on analysis, and coordination overhead. Those coordination jobs, he said, are the ones at risk, not because AI does the work better, but because the work itself was never the valuable part of the job.

His proposed fix, laid out in Output to Outcome, is what he calls the outcome loop: measuring outcomes instead of outputs, and applying the theory of constraints to find and remove the slowest point in a workflow. He was candid about what that means for management roles: "managers need to shift to being makers," with coordination, reporting, and escalation increasingly handled by agents while humans take direct, end-to-end ownership of results. That ownership, he said, "is an absolute key aspect, and that fundamentally now needs to be cross-functional," spanning product, engineering, design, and the business side rather than sitting in any single function.

A governance framework for enterprise AI agents

Maya Gonimah, CTO and co-founder of the AI orchestration platform Thread AI, spent her six minutes on a problem she sees repeatedly in enterprise AI deployments: by the time a company calls her team in, infrastructure is usually the real problem, not the model. "A lot of enterprises have a lot of ambition, but a lot of AI projects tend to stall at the pilot, or never make it into production," she said, a pattern she traced to her earlier work building AI infrastructure at Palantir.

Her team's response is what she called the controlled autonomy framework, built on three pillars: control, governance, and reliability. Control means an agent only has access to the systems and data its task actually requires, not broader permissions than that. Governance means every decision an agent makes can be explained after the fact. "You need to make sure that all information that passes through AI is traceable and observable," she said, so a team can answer an auditor's question about why a claim was processed or an alert triaged a particular way. Reliability treats agent workflows as a distributed systems problem: knowing when a multistep process should pause, and when it's safe to retry a step versus when it isn't, like a payment that shouldn't be charged twice.

Gonimah described failure patterns she has seen across customers: an insurance claims agent that pulled family members' records because it was trying to be thorough rather than staying scoped to what it should check, and checkout systems where a retried step caused a duplicate charge. Her advice for avoiding them was to pick one workflow rather than applying AI across an entire operation at once, and to design integrations so they can be reused. "You want to build an asset that compounds," she said, so a second team doesn't have to rebuild the same plumbing a first team already solved. The throughline across her examples was knowing exactly where a human needs to stay in the loop: "understanding where in the process you need to wake up the human and when is it okay to completely delegate to machines."

An open harness, not a kill switch, for agent safety

Craig McLuckie, co-creator of Kubernetes and now CEO and co-founder of Stacklok, closed the session with an argument against the two most common ways companies try to make agent deployments safe, and a case for a third.

The first common approach is the gateway: put a control point between agents and data, and another between the agent and the model. McLuckie pointed to open source projects in this space, including one Stacklok has contributed to, as examples of the pattern. The problem, he said, is that gateways govern access but not reasoning. "It's very difficult to actually understand what they're doing unless you have another LLM-based system watching them," which just pushes the same trust problem down a level.

The second common approach is the security operations center with a kill switch, built to catch an agent swarm going off script. McLuckie called this reactive by design: "you're slamming the barn door off the horse's bolted," and operators are reluctant to pull a switch with real operating impact once a system is running.

His alternative is to open up the harness, the system that reasons about an agent's work, spawns sub-agents, and decides which tools to invoke. Rather than watching an agent for bad behavior after launch, he argued for constraining it up front: limiting how many turns it gets, how many sub-agents it can spawn, and which tools it can call, at the level of an individual agent. He also argued every action needs an identifiable source, paired with a shift already underway at the model layer that separates tool execution from the agent loop so a tool doesn't run with the same permissions, environment, and credentials as the agent that called it. His summary for enterprises weighing how much to build versus buy: "own the harness, rent the models." On the career question, he was blunt about what doesn't change: the agent loop "is after all just another distributed application," and the architecture lessons from the cloud-native era, not a new set of agent-specific rules, are what get organizations to a safe deployment.