Sobhan Daliry, CPO & AI Strategy Leader at Pipefy – Interview Series

Sobhan Daliry, CPO & AI Strategy Leader at Pipefy, is an experienced product and technology executive who has led the company’s AI strategy since 2023, helping transform traditional business workflows into increasingly intelligent and autonomous processes. Throughout his career, Daliry has combined product strategy, organizational transformation, and technology leadership across startups and established companies. Before joining Pipefy, he founded and served as CEO of Polen.me and spent more than five years as CEO/CPO of NZN, where he led the company’s turnaround and product strategy. His earlier roles include Director of Product Management at PSafe, Product Manager at Peixe Urbano, and positions spanning digital services, telecommunications, consulting, and business development at Oi/Telemar, Claro, AIRCOM International, and Planeta Tecnologia.

Pipefy is a global process management and AI platform designed to help organizations automate and orchestrate business workflows. Founded in 2015, the company has evolved from a no-code process automation platform into an AI-focused orchestration environment that brings together AI Agents, workflows, forms, portals, applications, data, analytics, messaging, and integrations. Its platform enables teams to create and manage AI Agents using natural language and no-code tools while maintaining enterprise governance, security, and visibility. Pipefy’s AI capabilities include agents that can interpret documents, execute workflow tasks, support decision-making, interact with external systems, and orchestrate processes across areas such as finance, human resources, procurement, customer operations, and compliance.

Your career has taken you from telecom engineering at companies like Claro and Oi to product leadership at Peixe Urbano and PSafe, serving as CEO/CPO at NZN, founding Polen.me, and now leading product and AI strategy at Pipefy. How has that progression shaped the way you think about building AI products that solve real operational problems rather than simply showcasing new technology?

Telecom taught me that infrastructure has to work every single time, at massive scale, with zero room for “it mostly works.” A dropped call isn’t a demo failure, it’s a customer walking away. That mentality — reliability over novelty — never left me. At Peixe Urbano and PSafe I learned the opposite lesson: how fast consumer products live or die on whether they solve a real, felt problem today, not a theoretical one. Running NZN as CEO/CPO forced me to hold both truths at once — you can’t out-execute a bad thesis, and you can’t out-thesis bad execution. Founding Polen.me taught me the most expensive lesson of all: capital and time are finite, so every feature you build is a feature you didn’t build, and the cost of chasing an impressive demo instead of a real workflow shows up months later, not on stage. By the time I got to Pipefy, the question I ask about every AI feature is the same one I’d ask about a cell tower: does this hold up in production, under real load, when nobody’s watching? If an AI agent only works in a curated demo environment, it’s not a product — it’s a trailer for one.

You have led the formulation and implementation of Pipefy’s AI strategy since 2023. What assumptions about enterprise AI did you have at the beginning that have changed most as generative AI and AI agents have matured?

The biggest assumption I had to kill was that the model would be the bottleneck. In 2023, everyone — including me — was optimizing for “which LLM is smartest.” What actually turned out to be the bottleneck was context: does the agent know what the process actually is, what the guardrails are, what “done” looks like for this specific customer’s version of accounts payable. Model quality kept improving on a curve everyone could see coming; process context didn’t improve on its own, because nobody had structured it. The second assumption that flipped was about autonomy. I assumed the market wanted agents that acted completely independently as fast as possible. What enterprises actually wanted — still want — is bounded autonomy: agents that make real decisions inside rules they can’t break, with a trail that proves it afterward. Full autonomy without governance isn’t ambition, it’s just risk with a better UI. The market matured faster on trust requirements than it did on raw capability requirements, and that reordering is the single biggest thing I got wrong at the start.

Pipefy differentiates between relatively simple AI automation and AI agents that can reason through ambiguous situations, plan multiple steps, and execute actions across a workflow. How should enterprises determine when a task actually requires an AI agent versus when deterministic automation remains the better solution?

The test I use is simple: if you can write the rule, write the rule. Deterministic automation is still the right answer for anything where the decision tree is known in advance and doesn’t change — route this invoice to this approver if it’s under this amount. That’s not a job for an agent, and pretending otherwise just adds latency and unpredictability to something that was already solved. An agent earns its place the moment the situation has ambiguity a fixed rule can’t resolve — the invoice doesn’t match the PO exactly, there’s a missing field, the customer’s request doesn’t fit any of your existing categories. That’s where reasoning has actual value: deciding what to do next when “next” isn’t already written down. The mistake I see enterprises make constantly is building an agent for the 80% of cases that were already deterministic, because it’s flashier, and leaving the ambiguous 20% — the actual hard part — for a human to untangle manually. Flip that ratio and you’ve built something real.

There is a growing shift from standalone copilots toward “agentic orchestration,” where AI can coordinate processes spanning multiple systems. What separates genuine agentic orchestration from simply adding a large language model to an existing automation platform?

Dropping an LLM node into an existing automation flow gives you a smarter single step. Genuine orchestration means the AI has a persistent, structured view of the whole process — not just this task, but where it sits inside the sequence, what already happened upstream, what has to be true downstream for this to count as done. The difference is whether the intelligence has memory of the process or just memory of the prompt. A copilot answers the question you ask it. Orchestration coordinates action across systems that don’t natively talk to each other — your ERP, your CRM, a partner’s API — while inheriting the same rules, permissions, and audit trail the rest of the process already runs on. If you have to build a separate governance layer around your AI feature because the automation platform underneath it doesn’t have one, you don’t have agentic orchestration — you have a chatbot with API access, and those are not the same risk profile at all.

No-code AI agents potentially allow business teams to automate increasingly complex processes without waiting for engineering resources. How do you democratize that capability without creating a new generation of shadow AI, poorly designed agents, or security risks?

You don’t get safe democratization by asking business users to be more careful — you get it by

making the guardrails part of the paving, not a separate lane people have to choose to drive in. Every agent a business user builds inherits the same role-based access, the same audit trail, and the same business rules that already govern the process it’s built inside — they’re not optional configuration, they’re structural. That’s the actual answer to shadow AI: it’s not a policy problem, it’s an architecture problem. Shadow AI happens when the sanctioned tool is harder to use than the unsanctioned one, so people build their agent in a personal ChatGPT account or a random automation tool with zero visibility for IT. If the no-code experience is genuinely fast and the governance is invisible because it’s automatic, there’s no reason for a business team to go around it. The moment you make governance a manual step someone has to remember, you’ve already lost.

As AI agents gain the ability to make decisions and execute actions rather than merely recommend them, how should organizations decide where full autonomy is appropriate and where humans should remain in the loop?

The axis I use isn’t “how smart is the agent,” it’s reversibility and blast radius. If a wrong decision is cheap to detect and cheap to undo — routing, categorization, drafting — let the agent act and review in aggregate. If a wrong decision is expensive, hard to reverse, or touches money, compliance, or a customer relationship directly, keep a human in the loop for that specific step, even if the agent got the last thousand decisions right. The mistake is treating autonomy as a single dial you turn up for the whole workflow. Real processes are a sequence of steps with wildly different risk profiles, and the right design puts the human exactly at the step where a mistake is expensive — not everywhere and not nowhere. That’s also why human-in-the-loop, done right, isn’t a tax on speed — it’s how you build the confidence to eventually remove it from the low-risk steps, because you have the evidence to prove which decisions the agent consistently gets right.

Pipefy emphasizes governance through mechanisms such as audit trails, role-based access controls, business rules, and traceability within the workflow itself. Is embedding governance directly into the orchestration layer becoming essential as companies move AI agents from experiments into production?

It’s not becoming essential — it already is, and the companies finding this out the hard way are the ones who shipped agents into production first and are now building the audit trail after the fact. That’s backwards, and it’s expensive to fix retroactively. If audit trails, role-based access, and traceability aren’t native to the orchestration layer itself, every new agent you deploy is a new place governance can quietly fail — and you won’t find out until an auditor, a regulator, or an incident forces the question. Embedding governance in the orchestration layer means every action an agent takes automatically inherits the same rules and leaves the same evidence a human action would, without anyone having to remember to configure it separately. Enterprises moving from AI experiments to AI in production are discovering that the pilot’s success criteria and production’s success criteria are different: a pilot has to work, production has to be defensible. Governance is the difference between those two bars.

Many companies can demonstrate an impressive AI pilot but struggle to translate it into measurable business value. Which metrics should leaders focus on when determining whether an AI automation initiative is genuinely delivering ROI, and what are the most common reasons promising pilots fail to scale?

I distrust any AI ROI conversation that starts with “hours saved,” because hours saved by whom, verified how? The metrics that actually hold up under CFO scrutiny are things auditors can independently confirm: cycle time on a specific process, before and after; error or rework rate; the percentage of a workflow that now completes without human touch; and audit lineage coverage — can you show, for every agentic decision, why it was made. If you can’t produce that trail, you don’t have an ROI number, you have an anecdote. Pilots fail to scale almost always for the same reason: they were built to prove the model works, not to prove the process works end-to-end, in production, integrated with the systems the rest of the company already depends on. A pilot that lives in a sandbox, disconnected from the real system of record, will always look better than it performs once it’s wired into everything else that’s already running. Scale is a systems-integration problem wearing an AI costume.

You have also led organizational change initiatives at Pipefy while introducing new AI capabilities. From your experience, how much of successful enterprise AI adoption is actually a technology challenge versus a process, culture, and change-management challenge?

If I’m honest, successful enterprise AI adoption is 20% technology and 80% everything else. The technology mostly works now — that’s not where I lose sleep. What actually determines whether an AI initiative sticks is whether the people whose job changes trust the system enough to let go of the manual check they’ve been doing for ten years, and whether leadership is willing to redesign the process instead of just pasting AI on top of the old one. We went through this internally building our own engineering tooling — the technology to automate parts of how we build software existed well before the team actually trusted it enough to stop double-checking everything by hand. The unlock wasn’t a better model, it was visible proof, repeated enough times, that the system’s judgment matched theirs. Change management for AI isn’t a communications exercise, it’s an evidence-accumulation exercise — you earn trust in small, verifiable batches, you don’t declare it in a town hall.

Looking ahead, do you expect traditional workflow and business process software to evolve into orchestration layers where humans, AI agents, and enterprise systems continuously collaborate? If so, what will fundamentally change about how companies design and manage their operations?

Yes, and I think the shift is bigger than most people are pricing in. Workflow software used to be where you documented how work should happen. It’s becoming where work actually happens — a live runtime where humans, agents, and enterprise systems are all acting inside the same governed process at the same time, instead of a human using software as a passive record-keeper after the fact. What changes fundamentally is where the “system of record” actually lives. The record used to be a database that got updated once something already happened outside it. In an orchestration layer, the record and the execution are the same thing — the process itself becomes the interface, accessible not just through a screen but through an API, an MCP server, a CLI, so any agent, internal or a partner’s, can act inside it under the same rules a human would. Companies that treat this shift as “add AI to my existing tools” will keep hitting the ceiling I described earlier. The ones who treat their process layer as the actual product — the thing worth investing in structuring properly — are the ones who’ll compound an advantage nobody can copy just by buying the same AI model.

Thank you for the great interview, readers who wish to learn more should visit Pipefy.