Factory announced on October 30, 2026, that it had acquired Typedef, a startup building a context layer that exposes relationships across data definitions, pipelines and dashboards. The goal is to give Factory’s autonomous engineering agents, called Droids, better evidence when planning migrations, debugging pipelines and refactoring data models. Typedef separately confirmed the acquisition in a post by co-founders Yoni Michael and Kostas Pardalis.
The product thesis addresses a specific engineering problem: a code change can be correct within one file or repository while breaking something downstream. A renamed column might affect several transformations. A revised calculation might leave a dashboard running successfully while changing what its numbers mean.
Factory’s announcement describes the intended combination, but neither company disclosed deal terms, pricing for the combined offering, customer availability or an integration schedule. For now, this is a statement of product direction, not a dated release announcement.
What Typedef Adds to Factory’s Droids
Factory describes two complementary pieces. Its own platform supplies the harness that lets Droids work within a customer’s environment. Typedef supplies a context layer built from code that makes data relationships visible.
A harness is the surrounding system that gives an AI agent access to context, tools and an execution environment. The model can propose an edit, but the harness determines what information and actions are available as it works. Factory positions Droids as agents that plan, build and validate software within a company’s infrastructure, policies and approved models. Those are the company’s product claims, as described in its acquisition announcement.
Typedef’s contribution concerns what the agent understands before and during that work.
Data lineage describes where data comes from, how it changes and where it goes. A dependency map expresses the relationships between those steps. For an engineering agent, those relationships can help answer two different questions:
- Downstream: What could be affected if this definition or transformation changes?
- Upstream: Which earlier inputs or transformations could explain an incorrect result?
Factory says Typedef derives this context from code and exposes relationships among definitions, pipelines and dashboards. The announcement does not explain the extraction algorithm or provide a supported-platform list, so it would be premature to assume a particular parser, warehouse connector or graph-storage design.
The consequential detail is the intended scope. The context is supposed to extend across the data workflow, beyond the immediate code an agent has been asked to edit.
My view is that this is the strongest rationale for the acquisition: an agent needs a way to discover that a seemingly small task has a larger scope before it can plan that task responsibly.
Why a Locally Correct Change Can Still Break Reporting
Typedef’s founders frame context as a prerequisite for greater autonomy. Their announcement warns that an agent capable of writing SQL can still create risk if it cannot understand which pipelines, models and dashboards depend on that SQL. They describe the danger as:
“automating your way to a very expensive incident.”
That is Typedef’s characterization, not a finding from an independently evaluated deployment. The announcements provide no production measurements showing how much the combined technology reduces errors or improves migration planning.
A hypothetical example makes the technical issue clearer.
Suppose an orders model feeds a daily revenue transformation, which in turn feeds a finance dashboard. An agent receives a request to change revenue from a gross figure to a net figure that excludes refunds.
The edited query could remain valid SQL. Its output could retain the same column name and numeric type. Checks focused on whether the query runs might pass. Yet the dashboard could now display a different business measure under an unchanged label.
A dependency map could help identify the transformation and dashboard as consumers that need attention. The agent could then include them in its proposed change plan, identify validation work and explain why those extra steps are necessary.
The map would not, by itself, decide whether finance intended that change in meaning. That requires an understanding of the requirement and evidence that the resulting calculation matches it.
This distinction is central to evaluating the acquisition:
Lineage can identify where to investigate. Validation must determine whether the behavior is correct.
A column rename presents a more mechanical version of the same problem. Finding downstream references can help an agent coordinate related edits. A business-definition change is harder because the dependency may remain technically intact while its meaning changes.
Factory’s stated emphasis on both lineage and evidence is therefore important. A list of connected objects is useful, but a migration plan becomes more actionable when it explains which relationships make each object relevant and what needs checking.
How Lineage Could Improve the Three Target Workflows
Factory names migrations, pipeline debugging and model refactoring as target uses. These tasks benefit from related context, but they use it differently.
The following table translates those announced goals into practical engineering implications. It describes how lineage could help, not demonstrated behavior of a released integration.
| Workflow | Useful lineage context | Practical implication |
|---|---|---|
| Migration planning | Models, pipelines and dashboards that depend on a changing definition | Expand the plan to cover affected consumers and coordinate related changes |
| Pipeline debugging | Inputs and transformations upstream of an incorrect output | Narrow the investigation toward possible sources of missing or incorrect data |
| Model refactoring | Downstream consumers of a model whose implementation is changing | Identify where behavior-preservation checks may be needed |
For migrations, the main benefit is scope discovery. Before changing a schema or model, an agent needs to know which other components may require updates. Otherwise, a neatly completed task can leave unfinished work elsewhere.
For debugging, lineage can provide a route through the system. A bad dashboard value might originate in an upstream transformation or source input. Knowing the path does not identify the bug automatically, but it can make the investigation more focused.
For refactoring, the concern is preserving expected behavior while changing implementation. A dependency map can help identify the consumers against which that expectation matters. It cannot supply the expectation on its own.
These are credible uses of the context layer described by Factory. They also show why the acquisition is about more than retrieving additional files: the useful information is the relationship between components.
The Important Limit Is Coverage, Not Graph Size
A dependency map becomes valuable to an agent when it accurately represents the system involved in the task. The number of objects it contains is less useful than knowing whether it covers the relevant relationships.
Three questions follow from the companies’ stated approach.
Does the Context Reach the Actual Consumers?
Frequently Asked Questions
3 questions
1Why Did Factory Acquire Typedef?
Factory says Typedef’s code-derived context layer will give Droids clearer data lineage and evidence for planning migrations, debugging pipelines and refactoring models.
