Let an AI agent trigger your pipeline.

AI agents are starting to do real work in production — resolving a support thread, finishing a coding task, qualifying a lead. Each of those is an event worth acting on: something happened, and you'd like it enriched, recorded, and surfaced to the right people. The agent is the thing that made it happen. It shouldn't also have to be the thing that processes it.

Because the moment you want an agent's output to land somewhere useful — a Slack channel, your warehouse, a notification on your desk — it's tempting to make the agent do all of it: look up who the customer is, summarize the conversation, decide where it goes, post the message, write the row. That's a lot of machinery to bolt onto something whose actual job was answering the ticket.

what an ai agent should hand off

An agent is good at its task and at producing a structured payload about it — who it concerns, what happened, how it went. That's the part you want a model for. The work that comes after is a different shape entirely: enriching that payload, summarizing it down to something readable, classifying it so it can be routed, and getting it in front of the right person in the right place. None of that needs the model's judgment. All of it is steps a pipeline already knows how to run.

push the event; let the pipeline do the rest

So give the agent one new capability: a single HTTP call that pushes an event into a pipeline. It assembles a payload, POSTs it to the pipeline by id, and moves on to the next conversation.

# the one call the agent makes when it finishes a conversation
curl -X POST https://in.ingestlayer.com/v1/agent/invoke/agent-actions \
  -H "Authorization: Bearer $IL_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "sam@acme.io",
    "transcript": "... the whole conversation ...",
    "resolution": "refunded and apologized"
  }'
# enriching it, summarizing it, and telling you about it
# all happen in the pipeline — not in the agent.

That one call is the whole interface — a verb most agents already know how to use. Everything downstream — the enrichment, the summary, the classification, the notification — happens in the pipeline, which you set up once and the agent never thinks about again. The agent emits; the pipeline acts. Adding a new place for that event to go, or a new transform to run on the way, is a change to the pipeline, not a change to the agent.

one call in, enriched and routed out

Here's the pipeline behind that call — as the diagram you'd see in the app, or the file you commit. Flip between them. The agent's payload lands as an event and runs the same steps any other event would.

The agent sent a bare payload — an email, a transcript, a note. The pipeline turns it into something useful: enrich.person resolves the email to a real name and company, summarize collapses the transcript to the two lines a human actually needs, and classify reads the agent's report and files it under an intent you can route on. By the time it reaches a destination, a one-line agent call has become an enriched, summarized, classified event — and the agent did none of that.

you find out the moment it happens

Then it fans out, each destination shaped for what it's for. A churn risk lights up #support with the person resolved and the summary attached, so a human gets pulled in only for the ones that earn it. valve puts it in your menu bar in real time, so you feel the agent working without opening a dashboard. And Postgres keeps every one of them, enriched, whether or not anyone was watching. Same event, told three ways — that's the ordinary one-event-many-destinations fan-out, with the agent as the source.

The point is that the agent's work stops being invisible. It does its thing, pushes an event, and the right people hear about it in the right place — without the agent carrying a single Slack template or notification rule. You decide what's worth a ping and where it goes, once, in the pipeline.

how ingestlayer does this

The agent source is first-class. You create one, hand the token to your agent, and it POSTs any JSON body to a pipeline by id. From there the body flows through the same enrich, summarize, classify, and fan-out steps every other event uses — nothing in the pipeline knows or cares that the event came from a model. It's the same shape as sorting a webhook with a model, pointed at your agent instead.

What you get is an agent that focuses on its task and a pipeline that turns its output into enriched records and notifications you actually see. The judgment lives in the model; the processing lives somewhere built for it. The agent gets lighter, and the events it produces get a whole layer of work for free.

Give your agent a pipeline to push to — point it at one pipeline id and watch a single call come out the other side enriched, summarized, and on your screen.

il/eng