Gil Feig

Gil Feig co-founded Merge with Shensi Ding in 2020. His work addresses the engineering responsibilities behind connecting software products and AI agents to other companies’ applications: maintaining integrations, accommodating differences between systems, controlling access, and explaining where an automated answer or action came from.

From integration maintenance to founding Merge

Feig and Ding met in computer-science classes at Columbia. Feig subsequently worked at LinkedIn and Wealthfront before joining the recruiting platform Jumpstart as its first engineer. He became head of engineering, eventually managing 15 engineers. His account of that early engineering work explains how integrations became a substantial responsibility within a team building its own product.

Connections to applicant-tracking systems required continuing maintenance. When integrations broke, engineers had to interrupt product development to restore them, sometimes at the expense of promised features. Feig’s writing about those interruptions treats integration maintenance as an operational burden that reaches customers, support teams, and the product roadmap.

Ding encountered a similar problem at Expanse, where integrations affected sales and required dedicated engineering resources. They founded Merge to turn this repeated work into shared infrastructure. Merge’s unified API offered common data models and authentication flows across services, reducing the platform-specific work developers needed to perform themselves.

Designing around differences between systems

A shared interface still has to account for what each connected application can actually provide. Feig’s approach to adaptive integration interfaces makes those differences part of product design. An organization-chart application, for example, cannot assume that every HR system records parent-child relationships between teams. Metadata about supported fields and operations can guide the interface so it reflects the data available from the connected system.

Normalization also creates a tradeoff: a common data model can leave out fields that individual customers need. Feig and Ding devised Remote Data to expose raw third-party data alongside normalized objects, with Field Mapping making additional fields available. Developers could use the shared model while retaining access to information specific to a connected application. The contribution addressed a concrete limit of the unified API: simplifying differences between systems should not make useful data inaccessible.

His work on Merge Agent Handler extends that concern to agents that choose and perform actions. Credentials belong to individual users or service accounts, while configurable Tool Packs determine which connectors and operations an agent can access. Authentication, policy checks, and searchable request logs surround execution.

An equipment-request workflow makes the division of responsibilities concrete: an agent can receive a Slack message, create a Jira issue, and notify a channel using scoped access. The language model reasons about the workflow; the integration infrastructure manages the calls and their controls. Feig also helped build Merge’s Audit Trail in 2024, giving administrators visibility into actions within the dashboard.

Building context that agents can use and explain

Feig’s context-graph work applies the same attention to system capabilities and operational limits to the information an agent uses. He describes a running system that selects context for a particular user and request, balancing freshness, permissions, retrieval cost, and relevance.

His approach to customer-support questions illustrates the problem. Looking up why one customer was upset is different from finding which customers were upset over a period of time. Live API calls can support individual lookups, but searching across a large dataset requires a synced copy that supports semantic queries. Connecting MCP servers alone does not supply that capability.

Several ideas define his approach:

• Combine synced and live information: A router selects between stored context and live calls, and a summarizer assembles the result. A customer-status update might combine a cached account summary, current renewal information, and selected recent support tickets. Retrieving everything consumes API quotas, increases latency, and burdens the model with information it may not need.

• Include company-specific knowledge: Skills and memory belong in the context layer because business questions depend on local definitions. An agent needs to know how the company defines a happy customer, alongside the records it retrieves. Derived summaries can make that information easier to use without repeatedly processing all the underlying material.

• Keep provenance attached to derived information: Summaries need source identifiers, retrieval times, and access context. These details help explain an incorrect answer and determine when information has become stale or invalid. They also matter when permissions change: a summary can continue exposing a document’s contents after a user loses access unless the derived information retains the relevant access controls.

Across integrations and agent context, Feig focuses on making connected software dependable in use. A common interface must respect differences between applications; an agent’s context must preserve the freshness, permissions, and provenance of the information it contains.