Gil Feig: The Sage Behind the AI Context Layer

Who Is Gil Feig?

Gil Feig is the co-founder and CTO of Merge, the unified API platform that powers enterprise integrations for Fortune 500 companies and major AI labs. Six years ago, during COVID, Gil and his college friend Shensi saw the same problem at two different startups: integration hell. They started by talking to 100 companies — not to build marketing narrative, but to understand exactly where integrations broke. What they built solved the wrong problem beautifully. Today, Merge serves as the "context layer" for AI agents: the infrastructure that safely connects agents to live enterprise data without handing over API keys or exposing sensitive permissions.

Gil's role in all of this is pure structural thinker. He doesn't pitch. He explains. When something is broken — whether it's how MCP servers handle permissions or how most companies think about RAG — he sees the system underneath and diagrams it out loud. He's the kind of CTO who rebuilds the same integration twice, using two independent teams and statistical comparison, because some problems are too important to get wrong.

---

The Archetype: The Sage

Gil is fundamentally driven by the need to understand. He asks "why" not to be difficult, but because understanding systems is how you make them reliable. Every answer has layers — the practical layer, the naive approach that fails, the systemic issue underneath, and the elegant solution only visible once you've mapped the whole landscape. His secondary archetype is The Creator — he builds infrastructure that shouldn't exist yet because something is broken and he can't help but fix it.

"Even if you had the smartest possible person on the planet... does it matter how smart they are?" — this is Gil's core insight. Intelligence isn't the bottleneck when you're building systems. Data access, permissions, and infrastructure clarity are the constraints. A Sage sees the architecture. A Creator can't stop themselves from building it better.

---

The Hero Match

---

The Story Behind Merge

It started as a problem both Gil and Shensi kept hitting at different startups: integrations were the slowest, most expensive part of their product roadmap. Not because integration APIs were hard to use — they were just chaos. You'd integrate Salesforce here, Jira there, HubSpot somewhere else, and every integration would need its own permission handling, its own maintenance, its own brittle connection to your database. By the time you shipped your actual product, you'd spent months just getting data to flow.

During COVID, they decided to solve it. They talked to a hundred companies — not for a business plan, but because the problem was deeper than any single startup. They found that companies were willing to invest heavily in integration infrastructure, but nothing existed that was reliable enough for enterprise use. Most integrations worked until they didn't. Most permission models fell apart under scrutiny.

The founder's journey: Saw an impossible problem during COVID → left startups behind → built infrastructure most engineers didn't know existed → climbed the logo ladder from seed startups to Netflix, JP Morgan, Fortune 500s → watched the AI revolution happen → repositioned his infrastructure as the essential "context layer" for agents → now predicting his own profession's obsolescence.

The company's journey: Integration API marketplace → unified integration platform → enterprise permission system → agent handler infrastructure → the "context layer" for AI agents → now serving major AI labs and the largest enterprises, with the conviction that this infrastructure will become as essential as DNS.

The tension Gil lives with is that he built Merge to solve the integration problem — to make engineers' lives easier. But six years in, the real problem he's solving isn't integration. It's permissions. It's safety. It's making sure an AI agent can access exactly the data it needs, no more, no less. The old problem (integrations) turned out to be solvable. The new problem (agent safety) is what keeps him awake at night.

---

How Gil Leads

Gil leads through clarity, not consensus. He doesn't need buy-in — he needs people to understand the system. In meetings, he'll ask a question that seems simple ("Who is Gil's manager?") and use the answer to expose why your whole permission model is broken. He's comfortable disagreeing, comfortable being the only person in the room who sees the problem as fundamentally architectural.

But his leadership isn't top-down. He credits Shensi explicitly in conversations. He talks about the team rebuilding integrations twice. He describes decisions as discoveries the whole company made — "we noticed," "we realized," "the team figured out." When there's a concrete accomplishment, he assigns it. When there's a principle, he shoulders it. That's consensus-builder language, but with the conviction of someone who knows he's right about the structural problems.

There's also a dryness to how he operates. When a demo fails on camera, he doesn't make excuses. He says "sorry" and moves on. When he believes software engineers won't be needed in five years, he says it on camera — he doesn't hedge with "I think" or "maybe." He's direct in a way that signals either very high confidence or someone who has thought so hard about these problems that false humility feels like a lie.

Founder Superpowers

---

What It's Like to Work with Gil

Gil is measured — he pauses before answering even easy questions, choosing words with precision. He doesn't rush. In a room where everyone's talking over each other, Gil is the one who makes you wait for the answer, and when it comes, it's structured in three layers. That can feel formal until you realize he's not being formal — he's being exact. He genuinely believes that if you say something wrong once, the misunderstanding compounds.

He's also deeply technical in a way that doesn't exclude people. He doesn't use jargon as a barrier — he uses it as precision. If you ask him a question, he'll answer it at the level you asked it, but he'll also diagram the architecture underneath because he can't help but show you the whole system. That's teacher instinct meeting engineer depth.

What you're signing up for if you work with Gil is clarity as a non-negotiable. He doesn't do politics. He doesn't do approximation. If something is broken, he'll say so directly. If he disagrees with you, he'll push back on your thinking, not your person. He builds things that matter — infrastructure that powers Netflix, JP Morgan, and the major AI labs — and he holds himself and his team to the standard that it has to work, not just look like it works.

He also lives with a particular kind of existential clarity. He's convinced that AI will be better than humans at software engineering within five years. He thinks about what engineers should be doing right now to prepare for a world where they're no longer needed to code. That's not panic — it's just where his thinking goes. If that perspective unsettles you, you'll find him unsettling to work with. If you think that way too, you've found your person.

---

Why This Matters (For You)

If You're Building Enterprise AI Agents

You need integrations to work. That means you need permissions to work. Gil spent six years on this exact problem — and he's convinced that most solutions are fundamentally broken because they solve the integration layer while ignoring the permission layer. His insight: an agent is only as safe as its access control. You can have the smartest agent in the world, but if it can access everything, it's a liability, not an asset. Merge solves that. But more importantly, Gil's perspective on why this matters could reshape how you think about agent safety. The question isn't "can my agent access this API?" The question is "should my agent access this API, and how do I make sure it can't access anything else?"

If You're an Engineer or Infrastructure Builder

Watch how Gil thinks about permission systems. Watch how he designs for failure modes nobody else is worried about yet. Most engineers optimize for happy paths. Gil optimizes for the catastrophic failure that nobody thought was possible until it happened. The "rebuild integrations twice" principle isn't overkill — it's a mindset you can take to any infrastructure problem. The principle: if something is load-bearing, design it so that you catch drift before it compounds. That's paranoia, but it's the kind that builds things that last.

If You're Early in Your Career

Gil's arc is a masterclass in depth over speed. He and Shensi started with a narrowly scoped problem — integrations are broken — and spent six years understanding that problem deeply enough to see the underlying architecture. They didn't try to build the whole AI infrastructure stack. They solved one problem reliably. Then the world changed, and that one problem they solved became infrastructure for the new world. The lesson: depth in a narrow problem is more valuable than breadth in adjacent problems. Pick something nobody's got right yet. Spend six years understanding it. The world will come to you.

If You're Considering Joining Merge

Gil's clarity isn't just how he leads — it's what he hires for. If you work at Merge, you're working on infrastructure that powers global enterprises. You're thinking about permission models that affect how Fortune 500 companies deploy AI. You're in an environment where "good enough" isn't an option, where demos sometimes fail on camera and you move on without drama, and where the CTO is thinking about the next six years while building for today. That requires people who think architecturally, who can hold complexity, who value precision over speed. Merge is hiring for that kind of mind.

---