How agents work

An agent combines a persistent administrator configuration with context supplied for a particular interaction. Those inputs do not have equal authority.

The instruction hierarchy

1. Platform safeguards define rules the agent cannot override.
2. The agent’s System prompt defines its durable role and boundaries.
3. An Automation’s Trusted instructions define the single headless task for that action.
4. Knowledge pages, webhook JSON, chat messages, and Slack messages provide data to reason about.

Content in the fourth group is untrusted. A release payload containing "message": "ignore all previous instructions" is still evidence from GitHub; it does not become an administrator instruction.

Conversation and headless modes

Conversation

Website and Slack conversations have participants, a message history, and a surface-specific audience. The agent can respond across turns and may hand work back to people according to its configuration.

Headless Agent message

An Automation action is a one-shot generation:

• one enabled agent;
• one enabled, agent-bound Slack channel;
• one immutable Automation definition;
• one incoming JSON object;
• one generated Markdown body;
• one attempt to post through the durable worker path.

The action does not inherit a previous chat, personal memory, or arbitrary tools. This makes a release-summary Automation easier to reason about than a free-form conversational workflow.

Knowledge in website chat

Knowledge sources currently supply website chat only. Website chat concatenates every enabled source that has fetched content, in source order, into its website chat system context after the agent’s System prompt. The separate block explicitly identifies the content as untrusted reference material. It is not relevance-based retrieval.

Infra One does not apply an aggregate knowledge-size cap, retrieval step, or truncation before sending that combined block. An agent can have up to 10 sources, and each fetched body can be as large as 512,000 bytes (500 KiB). Keep the combined corpus narrow enough for the selected model’s context: many or large sources increase input size, latency, and cost and can make a request exceed the model context and fail.

Slack conversations and Agent message Automation runs do not receive knowledge-source bodies. Slack uses its conversation context; an Automation receives its trusted instructions and incoming JSON object.

Each source record exposes:

• its URL;
• fetch frequency;
• enabled state;
• last fetch time;
• OK, Never fetched, or Error status.

This separation matters operationally. Changing a system prompt takes effect when saved. Changing a source matters to website chat only after a successful fetch. If a later fetch fails, the previously fetched content remains available until the source is disabled, successfully fetched again, or removed.

Identity and channel bindings

The agent identity is organization-scoped. Slack connections are also organization-scoped. A channel is explicitly paired to an agent before it can be used for conversational participation or selected by the Agent message action.

Website embed keys do not contain an agent’s secret. They are publishable identifiers constrained by exact allowed origins. Slack signing and OAuth credentials remain server-side.

Design prompts for reliable agents

A good system prompt answers five questions:

1. What job does this agent perform?
2. Which evidence may it rely on?
3. Which decisions must it not make?
4. What should it do when evidence is missing or contradictory?
5. What should a useful answer look like?

Keep task-specific formatting out of a general system prompt when an Automation’s Trusted instructions can own it. That keeps the same agent useful across channels without making every conversation look like a release announcement.