[Case Study] From Portfolio Management to Predictive Playbooks: How Jay Khalife Built Entropy
Jay Khalife wasn’t hired to build AI systems. He built one anyway, turning fragmented operational data into simulations, strategy, and a reusable pattern other teams could adopt fast.
One of the most encouraging things about AI right now has very little to do with model benchmarks.
It has to do with who gets to build.
That was the real story behind a recent internal presentation from Jay Khalife, a portfolio director at Jigsaw, who built a system he calls Entropy. Jay’s job is not “AI engineer.” He manages a major portfolio inside a lean commercial organization. But instead of treating AI as a side assistant for note-taking or email cleanup, he used it to build something much more ambitious: a working system for turning fragmented customer data into strategy, simulations, and action.
That matters because it points to a bigger shift.
The future of AI inside organizations is not just better centralized tooling. It is also domain experts building their own leverage.
The problem Jay was solving
If you work in any operational role, you already know the shape of the problem.
The information you need is everywhere:
email threads
CRM records
meeting transcripts
Jira tickets
notes
tribal knowledge
product documentation
ad hoc context scattered across too many systems
The result is predictable. People spend too much time gathering context and not enough time acting on it.
Jay’s response was to create a system that could unify those inputs and make them useful.
His architecture combined:
a single intelligence layer for customer and portfolio context
a second brain reflecting the operator’s own frameworks, instincts, and knowledge
customer-specific intelligence summaries
scenario simulation across multiple strategies and offers
custom playbooks tailored to both the customer and the person executing
a feedback loop so real outcomes improve future recommendations
That’s not a prompt trick. That’s a system.
Why this stood out
Plenty of people talk about AI-first. Fewer actually work that way.
What stood out in Jay’s presentation was not just the technical creativity. It was the mentality behind it.
He didn’t wait for a formal product roadmap. He didn’t assume someone else needed to build the perfect internal platform first. He looked at the friction in his own workflow and started constructing the operating system he wished he had.
That is the behavior more organizations need.
We are entering a phase where the most effective people are not just users of AI. They are orchestrators. They are shaping systems around their own work. The best results often come from people with deep domain understanding who know exactly where the bottlenecks are, even if they are not traditional engineers.
Jay is a strong example of that shift.
Entropy matters because it travels
A lot of internal AI demos are impressive for 30 minutes and irrelevant by Friday.
This one didn’t feel like that.
Shortly after Jay shared the Entropy approach, someone in another part of the organization adapted the architecture to a very different operating context and had it implemented the same day.
The note back to Jay said the Entropy architecture mapped almost perfectly.
Status layers. Segmentation layers. Pain point clusters. A knowledge layer. A model of context bridging situations to frameworks. AI navigation working across the graph.
That is the signal.
The most important thing about Entropy is not that it worked for one person in one commercial role. It’s that the underlying pattern was reusable by another team almost immediately.
That means Jay didn’t just build a solution. He built a template.
It surfaced action, not just insight
The follow-up didn’t just validate that the structure transferred. It also surfaced actionable operational insight right away.
That’s important.
Useful AI systems should not just help us present cleaner summaries. They should help us see reality faster and identify where action is needed.
The follow-up also surfaced practical implementation lessons:
if you already have structured JSON, don’t force manual file creation
generate intelligence summaries and hub nodes programmatically
if you already have an agent scaffold, adapt the navigation layer instead of replacing everything wholesale
runbooks should account for teams applying the pattern to messy or mid-maturity datasets, not just ideal ones
That is exactly how internal AI work becomes real. Not through perfect theory, but through transfer, friction, adaptation, and learning.
What AI-first should actually mean
A lot of companies say they want to be AI-first.
Sometimes that means employees are encouraged to use chatbots more often.
That’s fine, but it is not enough.
AI-first should mean:
people closest to the work can build
systems get shaped by operators, not just handed down to them
reusable patterns spread horizontally
teams share what works
collaboration is easy when someone is onto something useful
That’s why stories like Jay’s matter.
He’s not just using AI to move faster inside an existing process. He’s redesigning the process itself.
That is a much more meaningful kind of leverage.
A note on collaboration
One of the healthier things happening around this work is that it hasn’t stayed isolated.
Jay has been building aggressively. Others have been helping sharpen it. And when people across the organization see something useful, they’re reaching out, adapting it, and extending it into their own domains.
That’s exactly the kind of behavior we want more of.
If you’re building something real, especially if you’re sitting in a business or operational role and think, “I’m not technical enough for this,” the answer is: you may be closer than you think.
And if you need help shaping the pattern, pressure-testing the approach, or figuring out how to adapt it to your environment, that’s a good reason to collaborate. The AI COE exists to help accelerate exactly this kind of work.
The bigger takeaway
The most exciting AI builders in organizations are not always the ones with “engineer” in the title.
Sometimes they’re the people with the clearest understanding of the problem.
Jay Khalife saw a mess of disconnected systems, repetitive context gathering, and reactive decision-making. Instead of accepting that as normal, he built something better.
That deserves attention for two reasons.
First, because the system itself is smart.
Second, because it demonstrates the mindset organizations need more of: don’t just use AI. Build with it.
And when you build something useful, share it. You may find the pattern travels faster than you expected.
David Proctor is VP of AI at Trilogy. He writes about AI infrastructure, enterprise automation, and what actually works in production.