Agentic Data Engineering Resources

Resource

Build Custom AI Agents With Flexible Logic and Shared Context

Build custom AI agents that route decisions between rules and LLM reasoning on one shared context layer, with Airbyte Agents.

Pedro Lopez

August 14, 2026

Summarize with AI:

A custom AI agent applies your business rules against data from every system you run, and its reliability depends far more on that data plumbing than on the framework you pick. Its design rests on two things: the logic that makes each decision, and the shared context those decisions read from. Teams that choose a framework first often discover in production that the agent sees three versions of the same customer, because each connected tool answers with its own fragment. When you design policy, context, and production tests together, the agent evaluates real records against a single, consistent customer view rather than guessing.

TL;DR

Use this build sequence to separate predictable decisions from reasoning tasks while keeping both on the same context layer.

Route each decision to a deterministic rule or large language model (LLM) reasoning by predictability, cost, and error recovery.
Every logic mode carries a context requirement; fragmented records break correctly routed decisions.
Build from policies to rules, then define the context contract, route reads and writes, and test against production-shaped data.
Pre-materialized shared context and runtime API assembly differ on latency, token use, and entity consistency.

Try Airbyte Agents to give every routed decision the same unified, permission-aware view of your customers.

What Does Flexible Logic Mean in a Custom AI Agent?

Flexible logic routes each decision an agent makes to either a deterministic rule or LLM reasoning. The route depends on how predictable the decision is, how much it costs to run, and how expensive it is to reverse a mistake. A refund-threshold check and an ambiguous support email are different kinds of decisions. Forcing both through a single mechanism produces an agent that is either too rigid or too unpredictable to trust.

Agentic tools that push every decision through the model demo well, then degrade under production load. The model re-derives decisions your business already wrote down. This frame flips the pattern so that the LLM handles interpretation and discovery, while deterministic code handles anything that can be specified in advance. The LLM agent architecture breakdown covers the runtime components of the reasoning loop itself.

Write actions get a third pattern: deterministic guardrails wrapped around an LLM proposal. The model can draft a credit or a Customer Relationship Management (CRM) update. A rule validates the amount against policy before anything executes, because a wrong write is expensive to reverse and a wrong draft is not. In practice, that means a ceiling on the amount the proposal cannot exceed, a human approver for anything above it, and an idempotency key so that a retried call cannot issue the credit twice. The rule authorizes the write.

"Custom" means making these routing decisions yourself rather than relying on a framework's defaults. Those routes only work when the required data is available, which is where the second layer comes in.

Why Do Custom Agents Need Shared Business Context?

Shared business context gives every decision a unified, permissioned view of the entities the agent decides on. Without it, decisions depend on whichever fragment a tool returns.

Customer data can sit in a CRM, a support tool, and a billing system, and the identifiers may not match. Say Salesforce knows "Acme Corp" by an account ID, Zendesk knows "Acme" as an organization, and Stripe knows a customer token that references neither. An agent querying each system through its own tool gets three partial views. It sees an account with plan tier and monthly recurring revenue (MRR), an organization with three open tickets, and a customer token with an overdue invoice. The join keys are different fields in each payload: a Salesforce account name, a Zendesk organization name and a Stripe customer email. Nothing in the three payloads says they describe the same company.

In this example, structured data from multiple sources has the same shape. Agents pull records from systems with different schemas for the same entity, so fields that should identify the same customer do not line up. A renewal decision made based solely on the Salesforce fragment misses the three open tickets in Zendesk and the overdue invoice in Stripe, so the decision can be wrong even when the logic is right.

A shared context contract fixes this by defining the entities the agent uses, the fields each decision reads, and the freshness it tolerates. Accounts, tickets, and invoices come from a single layer rather than being assembled per query. In practice, a contract like this produces agent-ready data, and a unified indexed context layer serves it. With the contract written down, the routing question becomes answerable decision by decision.

How Do You Choose Between Deterministic Rules and LLM Reasoning?

If you can enumerate every valid output for every valid input, use a rule. If the task can run through predefined code paths before the model runs, add a rule for that as well. When the path depends on what the agent discovers at runtime, use reasoning. Wrap costly write actions in deterministic guardrails either way.

Cost pushes hard toward rules wherever they suffice. Microsoft's guidance notes that a deterministic rule can execute in microseconds with zero inference cost, whereas LLM-backed reasoning incurs inference cost for routine work. Because that cost repeats with every model-routed run, work that looks cheap at pilot volume grows fastest in production. LangChain's workflow guidance makes the argument for auditability in architectural terms: workflows fit predictable problems, while agents fit unpredictable paths. In audited systems, interpretation can rely on probabilistic reasoning, whereas final authorization requires deterministic control.

That context requirement changes by decision type.

Decision type	Logic mode	Why	Context requirement
Fixed policy checks (refund thresholds, service-level agreement (SLA) tiers)	Deterministic rule	Same input must return the same output; audits require consistency	Current plan, MRR, or renewal values from source systems
Routing between known workflows	Deterministic routing with LLM classification input	Teams can draw the flowchart before the run	A unified customer record to classify against
Interpreting ambiguous input (ticket intent, email triage)	LLM reasoning	Teams cannot enumerate valid inputs in advance	Cross-system history to ground the interpretation
Multi-step investigation (why renewals slipped this quarter)	LLM reasoning in a loop	The path depends on what the agent discovers	Searchable indexed context across every connected source
Write actions (update CRM, issue credit)	Deterministic guardrails around an LLM proposal	Errors are expensive to reverse	Live source state via a direct API request

Teams that leave this requirement implicit make production reliability depend on accidental tool outputs.

How Do You Sequence the Build From Business Rules to Production?

The build runs in four ordered steps. Policies define the decisions, the decisions define the context contract, the contract defines the read and write paths, and the paths define the tests.

Step 1: Map Business Policies Into Decision Rules

Write each policy as an input-condition-action statement before touching a framework. "Refunds under $200 for accounts in good standing auto-approve" is a rule. "Figure out whether this customer is frustrated" is not, and anything you cannot write down as a condition goes to the reasoning column. Write policies first. This removes most of the routing ambiguity a framework would otherwise absorb into prompts.

Step 2: Define the Shared Context Contract

For every decision from Step 1, name the entities it touches, the fields it reads, and the freshness it tolerates. A renewal check needs the account's plan, renewal date, and MRR and can tolerate hourly freshness. A payment-status check before issuing credit cannot. Check the contract against what your sources can supply. An agent connectors catalog shows source breadth, and context engineering covers how to pick fields and manage freshness per decision, rather than dumping whole records into the window.

Step 3: Route Between Indexed Search and Live Actions

Reads that tolerate hourly freshness query the indexed layer; writes and freshest-state checks go to the live API. The context store path is read-only, so create, update, and delete operations always run as direct API requests, where the write guardrails apply. AI agent integrations support live API execution patterns, and a hosted Model Context Protocol (MCP) gateway at mcp.airbyte.ai/mcp provides clients with a single interface to access both paths.

Step 4: Test Against Production-Shaped Data

Synthetic test data is often cleaner than production data. Validate the logic against real record shapes, including duplicate accounts, mismatched entities, and records the agent's permissions should block. An agent that has never seen two Acmes in test will pick one arbitrarily in production, and that error looks like a logic bug when it is a data bug.

A Renewal-Risk Agent Reads the Same Account Across CRM, Support, and Billing

Take the question a Revenue Operations (RevOps) lead types into Claude or Cursor: "Which enterprise customers opened tickets this week and are up for renewal?" Step 1 splits it. "Enterprise" and "up for renewal" are deterministic filters on plan tier and renewal date. "Which tickets signal risk" is LLM reasoning, because ticket intent cannot be enumerated. Step 2 writes the contract around accounts, tickets, subscriptions, and invoice state. Accounts need plan, MRR, and renewal date from Salesforce; tickets need status and body from Zendesk; subscription and invoice state comes from Stripe. All three reads can use hourly freshness.

Step 3 routes every read to the indexed layer, since nothing here writes. Between steps, the agent carries the filtered account list and its per-account findings as working state, so the reasoning step scores risk against records the rules already qualified.

The naive tool-by-tool version can break at the join when three MCP servers return three lists keyed on IDs that do not line up. The model then has to guess which Zendesk organization is which Salesforce account. With a unified layer, the same question is resolved in a single query, which is the design goal for the builder who is not writing Python. That layer matches entities on shared identifiers where they exist and relies on the model reasoning across the unified records where they do not, with deterministic entity resolution on the roadmap. The next decision is whether to assemble that unified layer at query time or before the question arrives.

How Does Pre-Materialized Context Compare With Runtime Assembly?

Runtime assembly means the agent calls each source's API during the task and reconciles the results in the context window. Pre-materialized context means the system unifies and indexes the data before the question arrives. The two architectures differ on latency, token use, entity consistency, production behavior, and governance.

Dimension	Runtime assembly	Pre-materialized shared context
Latency	Each connected source adds a round trip before reasoning starts	One query against an indexed layer, resolved in under 500 ms
Token use	Raw API payloads flood the context window	The system filters typed JSON before the model sees it, cutting token load sharply
Entity consistency	Three Acmes reconciled on the fly	Agents reason across unified records at query time
Production behavior	Rate limits, auth failures, partial responses	Managed refresh, hourly to daily, with a direct API fallback for live state
Governance	Per-source credentials and audit surfaces	One credential flow and one audit surface across 50+ sources

The runtime call pattern creates latency that the table treats as an architectural cost rather than a measured figure. A pre-materialized layer instead resolves the request against one indexed source in a single round trip. In Airbyte's benchmarks, serving multi-source queries from that pre-materialized layer rather than assembling context at runtime cut token use by up to 80%, tool calls by 40%, and cost by 90%. The data path beneath the logic layer determines the latency, token usage, and entity consistency of those decisions, so the data decision precedes the framework decision.

How Do Airbyte Agents Give Custom Agents Shared Business Context?

Airbyte Agents provides a shared, indexed Context Store that agents query for business context, serving the context contract from a single layer instead of assembling it per query. Agent connectors populate that store across your sources, and Managed Auth isolates platform and connector credentials per workspace with one credential flow per source and automatic OAuth refresh.

Two execution modes cover both routing paths. Search runs reads against the Context Store, while Direct handles writes and freshest-state checks against the live API. A read-only agent can only describe the work that needs doing, while Direct lets the agent complete the action behind the same deterministic guardrails rather than just reporting it. You reach those modes through whichever interface best fits the build: the Web app for a hosted console, Agent MCP for MCP clients, the Agent SDK for programmatic control within your own orchestration, the Agent CLI for scripting and continuous integration workflows, and the API for direct programmatic access.

What Makes a Custom Agent Reliable Enough to Ship?

Reliability starts with the records the agent reads. A decision routed to the exact right mode can still complete even with incomplete records, so nothing alerts you, meaning the data layer decides whether correct logic produces correct outcomes.

Airbyte Agents keep those records on the same permission-aware context layer, so your orchestration can focus on routing logic and guardrails instead of rebuilding source joins for every run. Governed connectors, a shared Context Store, Managed Auth, and interfaces spanning the Web app, Agent MCP, Agent SDK, Agent CLI, and API let the same unified context reach whichever runtime you build on.

Get a demo to see how Airbyte Agents feeds custom agent logic with unified, permission-aware business context.

Frequently Asked Questions

Which Frameworks Work With Custom Agent Logic?

The routing patterns are runtime-agnostic. Airbyte Agents works with LangChain, CrewAI, LlamaIndex, AutoGen, OpenAI Agents SDK, Claude Agents SDK, Pydantic AI, and FastMCP so that you can keep your existing orchestration and swap in the shared context layer underneath it.

What Does Airbyte Agents Cost?

Airbyte meters usage in Agent Operations (AOs). The Free plan is $0/month with 1,000 AOs and no credit card required; Individual is $29/month with 5,000 AOs; and Team is $299/month with 10,000 AOs. Custom plans set their own pricing and AO allowances.

Is Entity Resolution Automatic?

Agents reason across unified records today: the model sees related records from every source together and connects them at query time. Our roadmap includes deterministic entity resolution at ingestion later in 2026.

Which MCP Clients Can Connect?

Claude, Claude Code, ChatGPT, Codex, Cursor, VS Code, and Windsurf connect through Agent MCP. The Web app, Agent MCP, Agent SDK, Agent CLI, and API share the same Context Store; identical query behavior across chat-window clients and IDE clients is not guaranteed.

Try Airbyte Agents

Airbyte connects your agents to all of your data and assembles context before they run. Build agents that actually know your business.

Try it free Talk to sales

Build Custom AI Agents With Flexible Logic and Shared Context

Related posts

Try Airbyte Agents