Follow one request before you wire up ten
AI agents use your company data by fetching permissioned records and knowledge from connected tools, then sending a curated context packet to a model for reasoning. In practice, how AI agents use your company data depends on the trigger, the fields each workflow requests, the instructions applied, and the actions approved after the run.
Integration marketing loves diagrams with arrows everywhere. That picture hides the part people actually care about: on Tuesday at 9:04, when an agent wakes up because a workflow fired, what leaves your systems and what still belongs to you when the run ends.
Without that trace, AI agent integration turns into a connector shopping list. You hook up Stripe, PostHog, GitHub, Notion, Linear, Slack, and Gmail because the checklist says so. Then someone asks why last week's report quoted a canceled subscription as active, and nobody can explain which API call lied.
Pick one job. Walk it once. The rest of your permissions and retention rules get easier.
The trigger decides how stale you can afford to be
Agents need a trigger. They start because something happened.
A workflow might run on a schedule: every Monday, summarize expansion accounts. An autopilot might listen for a pattern and act when it appears. A human might kick off the same path from Slack with a plain question.
The trigger sets the clock. Scheduled jobs can tolerate a few minutes of lag if your connectors sync on an interval. Event-driven jobs need fresher reads from the source table, not a cache from yesterday. If the trigger is wrong for the data, the agent will sound confident about old news.
Before you fetch anything, the platform usually records intent: which agent, which workflow version, who or what started the run. That metadata matters later when you audit a bad answer.
What gets fetched, and from where
Most useful agents blend live tool data with slower company knowledge.
Live data comes from integrations your team already uses. Billing state from Stripe. Product usage from PostHog. Open issues from Linear or GitHub. Threads and decisions buried in Slack or Gmail. Pages and playbooks in Notion.
Company Brain accompanies those connectors. It is structured knowledge your agents read from: definitions, policies, how you name plans, which fields mean what in your org. Analysis against Brain and source tables is read-only. The agent does not silently rewrite your canonical rows while it thinks.
A concrete example helps. Suppose your workflow is a weekly account health brief for customer success. The run might pull subscription status and recent charges from Stripe, active users and feature flags from PostHog, open bugs tied to the account from Linear, and the last few support-related emails from Gmail. In parallel it might query Company Brain for your tier definitions and the approved escalation ladder.
Each fetch is scoped. The agent should not receive every row in Stripe because the prompt mentioned a customer name. Connectors return what the workflow step asked for: one account id, a date range, a label filter. Permission boundaries from the integration account matter here. If the human who triggered the run cannot see a private Notion page, the agent should not either.
Fetching is not free context. Large payloads get trimmed, summarized, or replaced with pointers before the model sees them. Raw JSON is rarely dumped wholesale into the prompt. The platform chooses fields that the workflow instructions mark as relevant.
What actually gets sent to the model
The model never "logs into" your CRM. It receives a constructed packet: system instructions, the user or workflow goal, retrieved snippets, and tool results from the fetch step.
Think of the layers.
Fixed instructions come first: tone, output format, what to do when data is missing, when to refuse. Ephemeral facts from this run come next: subscription ids, usage deltas, ticket subjects, doc excerpts. Optional tool definitions follow if the agent may call another read or propose an action in a later step.
What you do not send is just as important. Secrets stay in the integration layer. Full card numbers, unrelated inboxes, and cross-customer exports should never enter the prompt because someone wrote a vague instruction. Good integration design treats the model as a reasoning engine over a curated slice, not a database dump.
Multi-step workflows repeat the cycle. Step one might classify accounts by usage drop. Step two fetches deeper history only for the short list. Each hop adds tokens. Each hop should earn its place. An agent that re-fetches the same Stripe object five times is burning money and inviting inconsistency if the record changes mid-run.
Hallucination risk drops when numbers and names come from retrieved text the model can quote back, not from memory of training data. The model still invents if the fetch failed and nobody surfaced the error. Wire explicit "no data returned" paths into instructions so the output says unknown instead of guessing.
Writes, proposals, and what gets stored afterward
When the run finishes, several kinds of residue remain.
Run logs hold the trigger, timestamps, integration calls, and often a redacted view of what context was assembled. That log is for operators, not for customers. It answers whether PostHog timed out or whether Brain returned an empty policy match.
The agent's primary output might land where humans already work: a Slack message with the brief, a Notion page draft, a comment on a Linear issue. Those destinations depend on how you configured the workflow.
Proposed changes to source systems are a different category. If the agent suggests updating a field, opening a ticket, or sending email, Company Brain and connected tools treat that as a proposal until a person approves. The busywork is drafted; the commit still has a human gate. That split keeps automation from becoming silent edits in production tables.
Autopilots that run on their own follow the same storage pattern. They may enqueue the next run, update internal workflow state, or append to a report series. They should not bypass approval rules you set for writes.
Retention is worth deciding early. How long do you keep prompts and fetched snippets in logs? Who can replay a run? Integration work is not only OAuth screens. It is lifecycle policy for sensitive company data sitting in agent history.
Permissions and messy schemas show up mid-flight
Two failures appear only when real data moves.
Access control has to follow the human, not the agent's enthusiasm. An integrated file, ticket, or repo branch that the requester cannot open must stay invisible even if the model argues creatively in the user message.
Schema ambiguity is the quiet one. The same field name in an HR or billing export can mean different things in different workspaces. If the agent interprets "status" wrong, the whole brief skews. Company Brain helps when you document what your fields mean in your language, not the vendor's generic label.
Integrations also break when vendors change APIs or when someone renames a Notion property on a Friday. Monitoring failed fetches beats blaming the model after customers have already acted on a bad summary.
How AI Agent helps
AI Agent is a no-code platform to build, deploy, and run AI agents that automate busywork: research, workflows, reports, and more. Workflows handle multi-step jobs on a schedule or when something triggers. Autopilots keep agents running on their own. Company Brain holds connected structured knowledge those agents read from, with read-only analysis against source tables and human approval before proposed writes go anywhere. It connects to tools teams already use, including Stripe, PostHog, GitHub, Notion, Linear, Slack, and Gmail.
Trace one request end to end before you scale the pile of connectors. Get more done without doing more.
What each part does
| Component | What it does | What breaks if it is missing |
|---|---|---|
| Trigger | Starts a run from a schedule, event, or human request | The agent has no defined reason to run |
| Data fetch | Retrieves scoped records and knowledge from connected sources | The model lacks current facts for its task |
| Context sent to the model | Packages instructions, goals, snippets, and tool results | The model receives too little guidance or relevant evidence |
| Writes and proposals | Delivers outputs and holds source changes for approval | Results have no useful destination or review point |
| Permissions | Limits access to records according to the requester's rights | Private data can reach the wrong person or workflow |
Frequently asked questions
What does it cost to use AI Agent?
AI Agent pricing starts at $49 for the Start tier, and Pro is $149. The total effort also depends on the connectors, workflows, approval rules, and retention policies your team configures.
How much effort does an AI agent integration require?
The work includes choosing a focused job, connecting the relevant tools, defining the fields and filters to fetch, and documenting company terms in Company Brain. Teams also need to set instructions for missing data, permissions, proposed writes, and run history.
What risks come with giving an AI agent access to company data?
The main risks include stale records, excessive context, incorrect field meanings, permission errors, and model guesses when a fetch fails. Scoped requests, human access boundaries, explicit no-data paths, and approval gates reduce those risks.
What can break during an AI agent run?
A vendor API can change, a source property can be renamed, an integration can time out, or a query can return an empty result. Monitoring fetch failures and recording the assembled context helps operators identify the failure before people act on the output.
What work does an AI agent replace?
An agent can replace recurring manual research, data gathering, report drafting, and routing work across connected systems. People still define the workflow, review proposed changes, and approve writes such as tickets, field updates, or emails.