ArcFlow
Company
Managed Services
Markets
  • News
  • LOG IN
  • GET STARTED

OZ brings Visual Intelligence to physical venues, a managed edge layer that lets real-world environments see, understand, and act in real time.

Talk to us

ArcFlow

  • World Models
  • Sensors

Managed Services

  • OZ VI Venue 1
  • Case Studies

Markets

  • Sports
  • Broadcasting
  • Robotics

Company

  • About
  • Technology
  • Careers
  • Contact

Ready to see it live?

Talk to the OZ team about deploying at your venues, from a single pilot match to a full regional rollout.

Schedule a deployment review

© 2026 OZ. All rights reserved.

LinkedIn
  1. Home
  2. Blog
  3. The Hiring Signal That Matters Most in AI-Native Teams

The Hiring Signal That Matters Most in AI-Native Teams

Article March 8, 2026

Share this post

In their first week at OZ, a new hire pointed an AI agent at an entire subsystem (hundreds of files, thousands of lines) and had it audit the whole thing. The agent identified patterns, flagged inconsistencies, and generated a structured report. The engineer reviewed it, identified the three issues that actually mattered, and proposed fixes. They didn't write hundreds of lines of code. They orchestrated intelligence and applied judgment. That, says Jagruti Patil, OZ's Head of People Operations, is the difference between a task-completer and a builder, and it's the difference that now separates good hires from exceptional ones in a world where AI agents can write, debug, and test code faster than any human.

What Comes After Code#

"In 2023, if you could write clean, fast, reliable code, you were valuable," Jagruti says. "That is still true. But the meaning of 'write code' has changed. AI agents write code now. They write it fast. They write it at scale. They debug it. They test it. They refactor it. The mechanical act of producing code is no longer the scarce skill. The scarce skill is knowing what to build and why."

She isn't dismissing technical ability. She's reframing it.

"Knowing how to code is like knowing how to read in the year 2000. Everyone needs it. No one gets hired for it alone. The question has moved one level up: can you think about systems? Can you design a workflow that combines human judgment with AI execution? Can you take a vague goal ('improve the replay experience for production directors') and turn it into a clear specification that both humans and agents can execute against?"

At OZ, this isn't a theoretical shift. It's daily practice. Every engineer works with AI agents as part of their workflow. The agents handle the systematic, repeatable parts: generating boilerplate, running test suites, formatting specifications, scanning for regressions. The humans handle the parts that require judgment: architectural decisions, trade-off analysis, user experience intuition, and the creative leaps that turn a good system into a great one.

"The people who thrive here aren't the ones who write the most code," Jagruti says. "They're the ones who get the most done. And the ones who get the most done are the ones who know how to work with agents as partners, not tools. They give clear instructions. They review outputs critically. They iterate fast. They orchestrate."

The Curiosity Signal#

When Jagruti evaluates a candidate, she listens for a specific quality before any other.

"Curiosity," she says. "Not curiosity as a word on a resume. Curiosity as a visible pattern in how someone thinks and talks."

She describes what curiosity looks like in practice. "A curious person doesn't just use a tool. They open it up and ask why it works the way it does. They don't just follow a process. They ask what would happen if the process changed. They don't just solve the problem in front of them. They wonder what caused the problem in the first place, and whether the cause reveals something about the system that no one else has noticed."

At OZ, where the platform spans hardware, AI models, spatial databases, broadcast production, and data APIs, curiosity is the quality that creates cross-domain understanding. An engineer who is only curious about their own domain sees one layer of the system. An engineer who is curious about everything sees how the layers connect, and connection points are where the most important problems hide.

"When I interview someone, I often ask them to explain something they learned recently that had nothing to do with their job," Jagruti says. "The answer itself doesn't matter. What matters is whether they light up when they talk about it. Do they get specific? Do they go deeper than the surface? Do they connect it to other things they know? That's the curiosity signal. And it's the strongest predictor I have found for who will succeed in a small, fast-moving team."

The curiosity signal is visible in the first ten minutes of any conversation. Curious people ask questions that go beyond the obvious. They make connections between domains. They get specific about things they find interesting. In a small team building a platform that spans hardware, AI, and broadcast production, curiosity isn't a personality trait. It's the quality that creates cross-domain problem solvers.

The Builder#

Jagruti uses a word that has become central to how OZ thinks about talent: builder.

"A builder isn't the same as an engineer," she explains. "An engineer can build what is specified. A builder can figure out what should be specified. A builder looks at a problem, designs an approach, selects the right tools (including AI agents), assembles the pieces, and delivers a result. They don't wait for a detailed task list. They create the task list."

This distinction matters because the nature of work has changed. When AI agents can execute detailed instructions with high reliability, the bottleneck moves upstream, from execution to definition. The person who can clearly define what needs to happen, and then orchestrate humans and agents to make it happen, is the person who creates the most value.

"At OZ, we don't ask how many lines of code someone wrote," Jagruti says. "We ask how much they shipped. What did they deliver? What problem did they solve? How did they use every tool available (including agents) to get there faster? The answer tells us whether they are a builder or a task-completer. We need builders."

She gives an example without naming the person. "We had someone join the team who, in their first week, used an AI agent to audit an entire subsystem (hundreds of files, thousands of lines). The agent identified patterns, flagged inconsistencies, and generated a structured report. The person reviewed the report, identified the three issues that actually mattered, and proposed fixes. That's a builder. They didn't write hundreds of lines of code. They orchestrated an agent, applied judgment, and delivered impact. In one week."

Drive and Urgency#

"I believe that speed is a value," Jagruti says. "Not speed for its own sake. Speed because the problems we are solving have real deadlines. A venue goes live on a specific date. A league season starts on a specific date. A match kicks off at a specific time. There's no option to delay the match because the system isn't ready."

This operational reality shapes the kind of talent OZ needs. Not people who rush and make mistakes; that is haste, not speed. People who feel urgency as a natural state. Who move toward decisions rather than away from them. Who treat a blocked task as a problem to solve now, not a problem to escalate and wait on.

"Drive is different from experience," she says. "I have interviewed people with fifteen years of experience who move slowly, not because they are careful, but because they have learned that in large organizations, moving slowly is safe. No one gets criticized for being thorough. Plenty of people get criticized for moving fast and getting something wrong. So they optimize for safety, not impact."

"At OZ, that calculation doesn't work. We're too small and our deadlines are too real. A person who takes three weeks to make a decision that could be made in three days isn't being thorough. They're being slow. And in our context, slow means that someone else has to move faster to compensate. That's unfair to the team."

She is careful about this point. "I am not describing recklessness. I am describing urgency. The person who says 'I can have a first version by tomorrow, and we can refine from there' is more valuable to us than the person who says 'Give me two weeks and I will get it right the first time.' The first person learns fast. The second person learns once. We need people who learn fast."

Jagruti Patil

Jagruti Patil

Head of People Operations

People & Talent Growth

“The people who thrive here aren't the ones who write the most code. They're the ones who get the most done, by orchestrating every tool available, including AI agents.”

Learning as a Daily Practice#

The pace of change in AI infrastructure is measured in weeks, not years. A technique that is state-of-the-art in January may be standard practice by March and outdated by June. This reality shapes how OZ thinks about learning.

"We don't have annual training programs," Jagruti says. "We don't send people to conferences and call it professional development. Learning happens inside the work. Every project involves something new: a new AI capability, a new deployment pattern, a new way to structure a specification. The expectation is that every person learns constantly, as part of doing their job."

This is where the curiosity signal connects to daily performance. A curious person treats every unfamiliar challenge as an opportunity to learn something. A non-curious person treats it as an obstacle. Over six months, the gap between these two approaches becomes enormous.

"AI agents accelerate learning," Jagruti adds. "When you work with an agent, you can ask it to explain a concept, generate examples, walk through trade-offs, or summarize a technical paper. The agent becomes a learning partner. People who treat agents as collaborators (who ask questions, explore alternatives, challenge the output) learn faster than people who treat agents as tools to automate tasks they already understand."

"The best people I have seen at OZ are the ones who are learning something new every week. Not because we require it. Because they can't help it. That's curiosity expressed as a daily habit. And it's the habit that keeps a small team at the frontier of a fast-moving field."

The Distributed Reality#

OZ operates across multiple time zones, languages, and cultures. This isn't a challenge to manage. It's a strength to design for.

"In a distributed team, the quality of your written communication is the quality of your work," Jagruti says. "There is no hallway. There is no quick tap on the shoulder. When you write a specification, a playbook, or a deployment checklist, the words you write are the only connection between your thinking and your colleague's understanding."

This is why OZ's everything-as-code culture isn't just an engineering preference. It's an organizational necessity. Every decision, every process, every production rule is encoded as a structured document, readable by humans, executable by systems, traceable across time. The culture doesn't tolerate ambiguity because the distance between team members doesn't allow for casual clarification.

"This is actually an advantage," Jagruti says. "Teams that rely on hallway conversations build implicit knowledge, things that everyone just knows but nobody has written down. When those people leave, the knowledge leaves with them. In our culture, the knowledge lives in the specifications. It is version-controlled. It is searchable. It persists. A new team member can read the specifications and understand not just what the system does, but why it was designed that way."

She connects this to hiring. "When I evaluate a candidate, I pay attention to how they would function in this environment. Can they write clearly? Can they structure their thoughts in a way that survives being read by someone in a different time zone, twelve hours later, without any additional context? That is the test. And it is a test that directly predicts success in our team."

In a distributed, everything-as-code organization, the quality of written communication isn't a soft skill. It's the mechanism through which the team coordinates. Engineers who write clear specifications create clear systems. Engineers who write ambiguous specifications create ambiguous systems. Hiring for communication clarity is hiring for system quality.

The Compound Team#

Jagruti returns to the idea from her previous interview (the human multiplier) but extends it into the world that exists now.

"In 2023, the multiplier was organizational design. Put the right person in the right role with full ownership, and they produce the output of three or four people in a conventional structure. That is still true. But now there is a second multiplier: AI amplification. Every person on the team works with agents that extend their reach. The combination (the right person, with full ownership, amplified by AI) produces extraordinary output."

"But this only works if the person has the qualities I described. Clarity, so the agents receive clear instructions and the specifications are unambiguous. Curiosity, so the person keeps finding new ways to leverage the tools. Drive, so the pace matches the demands of live infrastructure. And spark, the quality that makes the people around them better."

She pauses, choosing her words.

"We're not hiring for the world that was. We're hiring for the world that already exists. A world where AI agents are part of every team. Where the value of a human isn't in the mechanical work they can do, but in the judgment, creativity, and clarity they bring. Where the best teams are small, fast, and amplified, not large, slow, and specialized."

"The talent we look for isn't defined by years of experience or degrees from specific universities or mastery of specific programming languages. It's defined by how they think, how they communicate, how they learn, and whether they create energy or absorb it. Those qualities were always important. In 2026, they are the only qualities that separate good from exceptional."

"We call it spark. You know it when you see it. The person who walks into a conversation and makes everyone in the room think faster. The person who reads a specification and immediately sees what is missing and how to fix it. The person who hears about a challenge and their first instinct is to move toward it, not away from it."

"That is who we hire. That is who we are looking for. And if you are reading this and recognizing yourself in these descriptions (that curiosity, that drive, that instinct to create clarity and find solutions), we would like to hear from you."


This interview is part of the OZ Interview Series, profiling the team building the world model for the physical world.

All InterviewsAll with JagrutiLearn more about OZ