DEV Community: elliot hutchins

Your AI Agent Probably Belongs in the Data Pipeline

elliot hutchins — Thu, 22 Oct 2026 21:15:07 +0000

There's a question I keep coming back to with AI and data engineering:

Do we move the data to the agent, or move the agent to where the data already lives?

Because we're starting to put agents everywhere.

In the warehouse.

On the source databases.

Inside BI.

Writing transforms.

Watching queries.

Building DAGs.

Debugging pipelines.

And if you aren't careful, you end up with five agents, five sets of credentials, five different copies of context and a developer laptop somehow holding the whole thing together.

That doesn't feel like where this should end up.

Take a boring data stack

Nothing exotic.

You've got a handful of MSSQL databases.

Fivetran moves the data into Snowflake.

You've got some DAGs taking it through bronze, silver and gold.

Then BI sits on top.

Pretty normal.

Swap MSSQL for MongoDB, Snowflake for Databricks and Fivetran for Hevo if you want.

The names change.

The problem really doesn't.

Now add agents.

Where do they go?

The annoying answer is "everywhere"

Ask a data engineer where the agent belongs and you're probably going to get the classic answer:

"It depends."

And, unfortunately, they're right.

If you're doing BI, maybe the agent should sit near the warehouse and help users build queries and reports.

If you're using it for ETL design, maybe it needs access to your transformation layer, DAGs or SSIS packages.

Maybe it's managing transforms directly inside something like Hevo.

If it's acting more like a DBA, it probably needs to see query plans, database metrics, indexes and workload history.

Maybe another agent is responsible for data quality.

Another one owns schema changes.

Another handles lineage.

There are about a zillion places where an agent can be useful.

The interesting problem starts when those agents need each other.

Your org chart doesn't care about your pipeline

The database team might own the source.

Data Engineering owns ingestion and transforms.

Analytics owns the models.

BI owns what the business actually sees.

Dev might own the application producing the data in the first place.

Those teams aren't always under the same person.

Sometimes they barely talk.

The data doesn't care.

A bad query in the application can hammer the OLTP database, break an ingestion SLA, delay a transform and leave a dashboard showing garbage.

That's one problem.

Organizationally, it might belong to four teams.

And now we're about to recreate that exact same mess with agents.

A DBA agent discovers the issue.

A DE agent needs to change something downstream.

A dev agent needs to fix the source query.

A BI agent needs to know the data is currently questionable.

Those agents need shared context around the same goal, even if they have completely different permissions and responsibilities.

Otherwise we're right back to using people as the transport layer.

So who is actually running these things?

You can absolutely give one data engineer a monster setup.

Claude Code.

Five MCP servers.

Snowflake credentials.

Access to MSSQL.

AWS.

Databricks.

GitHub.

Whatever else you need.

Run the whole thing from their laptop.

And honestly?

It'll probably work.

It may even work really well.

Right up until you show the architecture diagram to Security.

There's also a more practical problem.

What happens when something occurs at 2 AM?

How do I trigger an agent running on someone's laptop because a CDC event showed up?

What happens when a FIFO event needs processing?

What if a database crosses a threshold and I want an agent immediately investigating it?

You can have the laptop wake up every so often and check something.

That's not the same thing.

If agents are supposed to become part of the data infrastructure, they need to behave like infrastructure.

Stop making the agent come looking for work

This is where I think the placement gets more obvious.

Put the agents near the tooling that's already moving the data.

Your ETL infrastructure already has a huge advantage.

It can reach the source.

It can reach the destination.

It already understands when jobs start and stop.

It sees failures.

It sees schemas.

It sees transforms.

It can react to events.

And, most importantly, it's already running 24/7.

You don't have to give some random new service network access to every database in the company.

You don't need a developer's laptop waiting around for something interesting to happen.

The infrastructure already exists.

Put the agent there.

That doesn't mean stuffing your warehouse into an LLM

There's another version of this conversation that immediately turns into:

"How do we get all our enterprise data into the agent?"

I don't think that's usually the right question.

Most of the time, don't move the data unless you actually need to.

Let the database do database things.

If the agent needs to understand a billion-row table, it probably shouldn't pull a billion rows into context.

Have it inspect the schema.

Look at statistics.

Run a query.

Sample the data.

Ask the warehouse to aggregate it.

Use the database as the compute layer it already is.

Then give the agent the result it actually needs to make the next decision.

That's very different from creating another giant copy of your data just so an LLM can stare at it.

Sometimes moving data does make sense

There are still cases where moving some of it is useful.

Maybe you want an isolated subset of production data for investigation.

Maybe the agent needs a smaller analytical working set.

Maybe you want to correlate data from several OLTP systems without hammering any of them.

Maybe you want cheap local execution for exploration before touching the warehouse.

Fine.

Move the slice you need.

But now that movement should be part of the pipeline too.

It should have lineage.

Permissions.

Retention.

A reason for existing.

"Claude needed it" probably shouldn't be your entire data governance strategy.

The agent belongs in the control plane more than the data plane

This is the distinction I think matters.

The agent doesn't necessarily need to hold the data.

It needs to understand where the data is, how it's moving and what it's allowed to do about it.

A pipeline fails.

An agent can inspect the source.

Check whether the schema changed.

Look at the ingestion job.

Check the target.

Inspect the transform.

Figure out what downstream models are affected.

Maybe fix the DAG.

Maybe create the migration.

Maybe tell another agent that the application needs a change instead.

That's much closer to a control plane than some giant AI database.

And now agent-to-agent communication actually makes sense.

The DBA agent doesn't need the BI agent's credentials.

The BI agent doesn't need production write access.

They need to be able to share enough context to work toward the same result.

Same problem.

Different domains.

Different permissions.

This is also where humans should show up less

There's no reason a pipeline failure should require three Slack threads before anyone starts fixing it.

The agents can do quite a bit before that point.

Discover the issue.

Figure out where it started.

Determine what's affected.

Gather the evidence.

Hand work to the appropriate domain.

Make low-risk changes.

Run validation.

Then bring a person in when there's actually a decision worth making.

Not because an agent needed someone to copy an error message from Snowflake into Jira.

We've already got APIs for that.

The boring infrastructure matters

Once you host agents in the data layer, all the unexciting stuff becomes really important.

Network access.

SSH tunnels.

Private connectivity.

Credential scoping.

Audit logs.

Shared state.

Tool permissions.

Agent-to-agent messaging.

Which agent can change what.

Which agent can only inspect it.

Which actions require approval.

This is the stuff that makes the difference between "I made an AI demo against Snowflake" and actually letting agents participate in your data platform.

The LLM is almost the easy part.

This is basically where I've landed

I don't think there's one database where "the agent" belongs.

There are going to be agents across the stack.

But I do think there should be a place where those agents run, share context, receive events and interact with the infrastructure without turning every engineer's computer into a tiny integration server.

For data, the ETL layer is a pretty damn good place to do it.

It already sits between the systems.

It already has the connectivity.

It already owns workflows.

It already reacts to changes.

We're just giving it something smarter than another DAG operator.

Shameless plug: this is the direction I'm building SchemaBounce around.

Transforms and DAG management are in the same environment as the agents. There's managed DuckDB when you actually do want to offload a working subset of OLTP or warehouse data, a SQL workbench, private VPN and SSH connectivity, A2A messaging between agents, and permission boundaries so the DBA agent doesn't automatically get to become the everything agent.

Basically, the boring pieces you start needing as soon as you try to take "AI-managed data infrastructure" past a laptop demo.

I've seen a lot of tools bolt an agent onto one part of the data stack.

Query the warehouse with AI.

Generate SQL with AI.

Build a DAG with AI.

Useful stuff.

But that's not really the problem I'm interested in anymore.

I want the source database, ingestion layer, transforms, warehouse and BI side to be able to work on the same problem without a human spending their day moving context between them.

The data already has a pipeline.

Maybe the agents should use it too.

Let's Share Sessions. And MCP.

elliot hutchins — Fri, 04 Sep 2026 04:36:31 +0000

Shared AI sessions make a ton of sense.

We already do a janky version of this today.

I talk through something with ChatGPT, copy the useful parts to a friend, and they keep going from there.

Or I share the conversation.

Or two people work through the same problem together.

Nothing weird about that.

Until the chat has tools.

Now give that shared session MCP

Say two developers are working in the same Claude session.

Both have Google Drive connected.

Maybe GitHub too.

Maybe HubSpot.

AWS.

Whatever.

Now we have a problem.

Most MCP authentication today is built around one person.

I connect Google Drive. OAuth happens. The agent can access my Drive.

Perfectly reasonable when I'm the only person using the session.

Now add User B.

User A has their Google Drive connection.

User B has theirs.

User B says:

Find that document User A was looking at and copy it into my Drive.

Which credential gets used?

If the answer is "the agent figures it out," you've already lost.

The model is not your security boundary

This is the part I think we need to be way more aggressive about.

Do not give a shared agent a pile of user credentials and expect the prompt to enforce permissions.

That's not security.

That's asking nicely.

If everyone is intentionally using the same shared resource, this is easy enough.

Use a service account.

Use an API key.

Give that MCP connection exactly the permissions the team needs.

Now the shared session has a shared identity.

Great.

But a lot of services don't work that cleanly.

Google Drive is tied to users.

HubSpot may be tied to users.

Facebook definitely gets weird.

Sometimes OAuth is the only realistic authentication model.

So now what?

Every tool call needs an actor

I think this is the piece most shared-agent designs are missing.

Don't attach the credential to the chat session.

Attach authorization to who caused the tool call to happen.

Every person in the conversation already has an identity.

Use it.

User A sends a message.

That message carries User A's identity through the agent runtime.

The agent decides it needs Google Drive.

The request hits an MCP gateway.

The gateway sees that User A initiated the request and exposes only the MCP connections User A is allowed to use.

User B sends the next message?

Same conversation.

Same context.

Different authorization.

That should be non-negotiable.

Here's the weird part

User A says:

Find my architecture document for project X.

The agent calls Google Drive using User A's authorization.

It finds the document.

The shared session now knows that document exists.

Then User B says:

Cool, copy that file somewhere I can download it.

The model understands exactly which file User B means.

That's good.

That's the whole reason shared context is useful.

But User B did not suddenly gain permission to User A's Google Drive.

Their request hits the gateway.

Their identity doesn't unlock User A's connection.

The tool call gets blocked.

Shared context does not need to mean shared authorization.

Those are completely different things.

We should stop designing systems like they're the same.

And yes, there is an obvious hole

User A can still say:

Print the entire document into the chat.

If the agent does that, congratulations, the document is now in the shared conversation.

User B can read it.

The gateway can't put the toothpaste back in the tube.

But that's a different security decision.

User A authorized bringing that information into shared context.

What we're preventing is User B independently reaching back through User A's credentials and pulling whatever they want.

There are probably additional controls you'd want.

Maybe sensitive tools can't dump full documents into shared sessions.

Maybe some tool output is only visible to the requesting user.

Maybe content gets classified before it enters shared context.

There are a lot of nasty edge cases here.

But none of that changes the basic rule:

The model should not get to decide whether a user is authorized.

Put MCP behind a gate

I think MCP gets much more useful once you stop treating the connection itself as something the agent owns.

Put a gateway or proxy in front of it.

The agent asks for a tool.

The gateway decides whether the request is allowed.

Who initiated it?

Which connection can that person use?

Which tools are allowed?

Which resources can that connection access?

Is this tool even allowed inside this shared session?

Only after those questions get answered should anything hit the actual MCP server.

That also gives you somewhere sane to put:

audit logs
rate limits
approvals
credential rotation
policy
resource scoping

Stuff we already know how to do.

We're just strangely willing to forget all of it once an LLM is involved.

Shared sessions get a lot more useful after this

Once auth lives outside the agent, things get interesting.

A team could share one GitHub service account.

User A could have a private Google Drive connection.

User B could have a private HubSpot connection.

Everyone can still work inside the same conversation.

The agent gets the shared reasoning context without getting universal access to every connected system.

That's a pretty important distinction.

The session owns context.

The user owns identity.

The gateway owns authorization.

Don't collapse those into one blob.

That's how you end up with a shared AI session that is one clever prompt away from becoming an internal data exfiltration tool.

Shameless plug: this is one of the workflows I'm working through with SchemaBounce. A lot of the design is built around keeping agent context, identity, MCP connections and authorization separate instead of letting one session become God Mode.

The more MCP moves from demos into real infrastructure, the less comfortable I am with agents holding credentials directly.

Give the agent tools.

Give the infrastructure credentials.

And never let "we share a chat" quietly become "we share access to everything."

Let me know what you think.

Why Are Your AI Automations Still Running on Your Laptop?

elliot hutchins — Mon, 24 Aug 2026 23:46:14 +0000

You wouldn’t run your SaaS off your laptop.

So why are we doing it with AI?

A lot of the AI automation I see right now still depends on a person sitting in the middle moving information around.

Production throws an error. Someone checks AWS logs, drops them into Claude, figures out what happened and creates a Jira ticket.

Another dev picks up the ticket and has an agent make the change.

Someone reviews it. QA tests it. Maybe DevOps has Codex check the deployment logs over MCP.

Information comes in. A decision gets made. Something happens.

Pretty simple.

Except we keep using humans to connect each step.

We are basically expensive middleware

Most of these systems already have APIs.

AWS knows an error happened.

GitHub knows what changed.

Jira knows what needs to be done.

CI knows whether the tests passed.

The agent can read the code.

So why does someone still need to copy the error out of CloudWatch, explain it to an agent, copy that answer into Jira, then have someone else feed Jira back into another agent?

We’ve automated the tasks without really automating the workflow.

That’s the part I think is going to change.

Where do you actually need a human?

This is probably the harder question.

And every team is going to have a different answer.

Some changes should absolutely require approval. Some companies have compliance requirements. Sometimes the agent is just wrong.

AI output is still pretty meh in plenty of cases.

But it’s getting harder to argue that a human needs to be involved in every step.

For a lot of work, I think you really need one or two human decisions.

Did we understand what we are trying to do?

And later:

Did we actually do it?

Everything between those two questions is fair game.

Even the second one gets interesting when the intent is specific enough.

If the requirement says this endpoint needs to return X, these tests need to pass, latency can't increase past Y and this error should stop appearing in the logs... a machine can check most of that.

Probably better than someone clicking around dev for ten minutes.

Take a boring production bug

Say a service starts throwing a new error.

That error could kick off a job automatically.

Pull the surrounding logs.

Check what deployed recently.

Look through the relevant code.

Figure out the likely cause.

Create a Jira ticket with the useful context already attached.

Then pick that work up, create the branch, make the change, add the test and open the PR.

Deploy it to dev.

Run the E2E tests.

Check the logs.

See if the original problem is still happening.

Nobody has needed to do anything yet.

Maybe that's where a developer gets involved.

They get the issue, the change, the test results and what happened after deployment.

Approve it or don't.

If you want to be more conservative, put a person at the beginning too. Let them approve the diagnosis before spending tokens and changing code.

If you want to hit the gas, make merge approval the checkpoint.

The exact line isn't really the point.

The interesting part is how much work happens before you need that line at all.

The part we're missing is memory

We already have good agents.

Claude Code can work through a codebase.

Codex can work through a codebase.

MCP gives them access to other systems.

The piece I keep coming back to is what happens when one agent is done.

Where does everything it learned go?

Right now the answer is often a chat window.

Or a terminal.

Or Jira after a developer manually summarizes it.

That's not great.

The error, logs, investigation, decisions, code changes, test results and deployment results should live somewhere the next step can use them.

A database would honestly solve a surprising amount of this.

Call it state, context, memory, whatever.

Just stop making a person carry it around.

This is a lot of what I've been thinking about while setting up my automations on SchemaBounce. I started out thinking about where agents do work. Increasingly I think the more interesting problem is the infrastructure that lets them keep doing work without needing somebody to babysit every transition.

Which gets me back to the laptop

You can build almost all of this locally today.

A couple MCP servers, Claude Code or Codex, some AWS access, GitHub, Jira and a little glue code.

I've done versions of it. A lot of developers have.

But eventually you end up with a pretty funny architecture:

Your laptop has become production infrastructure.

Close the lid and your automation is gone.

VPN drops? Gone.

Token expires? Gone.

Someone else wants to use it? Have fun recreating your setup.

Want to know exactly why an agent made a decision three weeks ago? Hopefully you kept the terminal open.

Once these things are actually doing parts of the SDLC, they probably need the same boring stuff we expect from everything else we run.

Hosted somewhere stable.

Scoped credentials.

Persistent state.

Logs.

Retries.

Timeouts.

Versioned workflows.

An audit trail.

Observability.

Not because any of that is exciting.

Because the goal shouldn't be to build the world's coolest prompt running on a MacBook.

The interesting version is when an error can happen at 2 AM, the system can investigate it, put together a fix, prove what it tested, and have something useful waiting for a developer in the morning.

No copy/paste required.