Intelligence infrastructure for data teams

The data agent your team should not have to build.

PDC works with data teams to build agents that investigate the real environment—not a simplified copy of it. They answer difficult questions, test assumptions, and surface problems before a customer or executive finds them.

Explore the direction Discuss an engagement

Most data agents are given a model of the system instead of the system itself.

General-purpose agents can reason across long investigations, but they arrive without the data-specific methods or access needed to do the work. Teams compensate with semantic views, lineage graphs, catalogs, and retrieval indexes—useful representations that cannot contain every exception, code path, or decision.

This is the data equivalent of asking a coding agent to understand a codebase from its documentation while withholding the code. For a difficult investigation, reading the Airflow DAG that built a table can be more useful than looking at a diagram of it. The answer may also depend on the pull request that changed the DAG, the ticket behind the request, and the conversation that documented the exception.

Representation	Useful for	Where it breaks
Semantic view	Known metrics, approved joins, and recurring questions.	Unexpected questions, exceptions, and changing business logic.
Lineage graph	Showing dependencies between data assets.	Code paths, runtime behavior, operational history, and intent.
Catalog or document	Ownership, descriptions, and conventions.	It ages separately from the system it describes.
Primary systems	Current code, executions, discussions, and decisions.	Distributed across tools; requires safe connectivity and active investigation.

The context layer is access to primary sources.

The model is capable. The missing product is everything that lets it investigate your company.

Modern agents can sustain a thirty-minute investigation: reading code, tracing executions, comparing evidence, and revising a hypothesis before returning an answer. The bottleneck is access to the right evidence and a reliable method for using it.

That context crosses vendor boundaries. A warehouse platform sees the warehouse. An orchestrator sees its runs. A model provider sees only what it is given. No single vendor owns the code, Jira tickets, GitHub history, Slack conversations, and data required for the whole investigation.

PDC operates across those boundaries with explicit, read-only permissions. Its context layer is a map of where to look and how to investigate—not a second copy of the organization that must be kept current by hand.

PDC begins with hands-on work inside real data organizations. The parts that repeat—connectors, permissions, investigation tools, model routing, and audit traces—can become deployable infrastructure instead of another one-off internal project.

The useful agent is not just waiting for a question.

Investigate on demand. Keep watch when nobody is asking.

Q&A is the front door, not the whole job. A useful agent should trace a metric change or pipeline failure when asked. It should also review the quiet failure modes data teams routinely miss: tests that stopped running, configuration that drifted, slowly accumulating errors, and changes whose downstream impact was never checked.

Connectors are necessary, but not sufficient. The system also needs a data engineer's method: establish where and when a change began, form competing hypotheses, distinguish intended changes from anomalies, and attach evidence to the conclusion.

Mode	Job	Output
On demand	Investigate a question, metric change, or data incident across the systems where it was produced.	A defensible explanation with source-level evidence.
Continuous assurance	Review tests, executions, configuration, and behavior for failures the existing controls did not catch.	A prioritized finding with impact, evidence, and a recommended next step.

Early engagements are deliberately hands-on: connect a small set of systems, choose a few consequential datasets and failure modes, and run the work alongside the team. The repeatable pieces earn their way into a hands-off product.

Built close to the problem.

PDC is built by John McCrary, a data and software engineer who has spent most of the past decade inside medium and large data organizations.

He has built the pipelines, internal platforms, and early data agents—and used the home-built systems—that make this problem tangible. The premise is practical: even capable teams lose months to glue code, stale context, and architecture work that has little to do with the data products their customers actually need.

John's writing LinkedIn

We are looking for five design partners.

If your team has tried to build an internal data agent—or is tired of discovering data issues late—we should compare notes. We want to work with 10–50 person data organizations running a mature stack inside a complex business. Bring us one real question, incident, or failure mode that required a senior engineer to untangle. We will investigate it with you and learn what should become product.

Discuss a design partnership hello@pulaskidata.com