What we learned shipping agentic workflows
Poonit Mistry
Manager
Evolution Analytics, LLC.
Posted: September 8, 2026
“The hardest part wasn’t getting the AI to work or wiring up the Jira API. It was deciding what the pipeline should actually do: what questions to ask, how to score the output, what a good intake artifact looks like. Once that was clear, Snowflake made the rest easy.”
Poonit Mistry, Manager, Data & AI · Evolution Analytics
Organizations with DataOps teams know this pattern well: a new data source request comes in, and before any pipeline gets built, your most experienced engineers (the ones who should be designing systems) are stuck doing intake. Reading tickets. Researching vendor APIs. Estimating complexity. Writing Jira Epics from scratch. It is the kind of repeatable, predictable work that compounds quietly until it is consuming days of engineering capacity every sprint.
When we stood up this DataOps team, we designed around that problem from day one. Intake automation was baked into how the team was meant to operate, and Snowflake was the natural home for it. That is where the data is, where the team works, and where any production workflow at this client needs to run.
This is the kind of workflow we call WIRE™, a resolution layer we build on Snowflake to move defined work items through repeatable, governed processes. Here, the work item is a new data source request. WIRE takes it from intake through research, complexity scoring, task creation, and documentation, turning what was previously hours of senior engineering work into an automated workflow. Here is how we built it.
Six steps, two to four hours, repeated for every data source, by your most experienced engineers.
How it works: the technical context
The pipeline is a Python stored procedure. It reads the intake ticket from Jira over an external network integration, calls AI_COMPLETE with a structured research template, runs a deterministic complexity scorer against the AI’s output, then writes the Epic and stories back to Jira. That’s the whole thing. No orchestration layer, no message queue, no separate service to deploy or maintain.
The research template is what made it reliable. Instead of asking the AI to summarize a vendor in whatever format it chose, we gave it nine structured fields to fill in: source overview, integration assessment, technical findings, data scope, risks, blockers, scoping questions, next steps, and research sources. The AI fills in those fields. Everything downstream reads from them. No prompt output parsing, no regex, no hoping the format holds.
We ran it against roughly ten intake requests before putting it in production. The research quality was consistently better than what an engineer would produce in the same window, mostly because the AI doesn’t skip the tedious questions. Nobody manually checks whether an API uses cursor-based or offset pagination. The AI does it every time.
Fig 1. Every stage runs inside Snowflake. No separate systems, no manual handoffs.
Key insight: Structured templates beat free-form prompting. The moment we stopped asking for a “summary” and started asking for specific fields, the output became something we could actually act on.
What we built and why it works
A reasonable question is: why not just use a Cortex Agent and let it decide the steps dynamically? We considered it. A Cortex Agent can call Jira natively, pick which tools to invoke, and adapt the research process. That sounds appealing. But the intake workflow has a fixed sequence (read the ticket, research the source, score the complexity, create the tasks) with no branch logic that an agent would help with. The stored procedure runs the same sequence every time and costs a fraction of the price. For a workflow where the steps are known in advance, determinism wins.
We did use a Cortex Agent for one piece: web search. For vendors where the AI’s training data is thin (niche systems, proprietary APIs), an opt-in flag switches the research step from AI_COMPLETE to DATA_AGENT_RUN, which pulls live documentation and vendor specs via Snowflake’s native Brave search integration. No external API keys, no network rules to configure on our end. The rest of the pipeline stays identical either way.
Two other decisions that paid off early. First, the AI model is a database row, not a line of code. When our model was deprecated mid-project, we updated one row in LLM_CONTROL and the pipeline kept running. No deployment, no PR, no outage. Second, the complexity scorer deliberately keeps the AI out of the final number. The AI surfaces facts. A separate rules function produces the estimate, logging a reason for every point it adds or subtracts. A project manager can read that log and push back if something looks wrong. The AI generates evidence. The algorithm makes the call.
The results were immediate.
The time saving is real. Three hours to forty-five seconds is hard to ignore. But that’s not what changed the most.
What actually changed is consistency. Every source request now gets the same research depth, the same scoring model, the same Jira structure, regardless of which engineer handles it or how busy the week is. The knowledge that used to live in a senior engineer’s head is now in a prompt template and a scoring function that anyone on the team can read, question, and update. For a team managing fifty-plus integrations, that shift compounds quickly.
What confirmed the approach was how little new infrastructure this needed. The AI, the security model, the audit trail, the cost tracking: all of it ran inside the Snowflake environment the team already trusted. We didn’t introduce another standalone system. We just used the one we had, more fully.
The open problem is the feedback loop. The complexity scorer uses static rules today. What we want is for it to learn from actuals, feeding completed delivery timelines back in to tune the estimates over time. Early indicators are promising, but the dataset is still small. That’s the next post.
