What happens between a request and its result?

Follow a request through identity checks, source retrieval, model execution, and review. The architecture also needs to account for records, connected tools, and the people who administer the system.

Request an AI setup review Read this page

Architecture

Where the work runs
and data goes.

Select a layer to see who can use it, what it connects to, and which information it keeps.

An orange request marker moves through six separated layers representing people, permissions, data, model execution, tools, and records. — Follow one illustrative request through the layers. Select a layer to read how it handles the request.
Conceptual architecture illustration

The deployment review confirms the location, access rules, and connections for each layer.

Layer 1

Who owns this workflow?

Name the person requesting the work and the person responsible for reviewing it. Define the task before giving an agent access.

Boundary: Authenticated team members
Connection: A request with an approved purpose
Record: Requester, workflow owner, intended outcome

Layer 2

One security plane enforces the rules.

Velociti’s harness sends all incoming and outgoing communications through a controlled communication lane. Its shared security plane enforces your access and route policies. Monitoring agents watch communications and policy activity 24/7.

Boundary: Your access and approval policy
Connection: Incoming and outgoing traffic through the harness lane
Record: Requested route, policy decision, monitoring record

Layer 3

Choose which sources the agent can read.

Specify the repositories and storage locations the workflow needs. Production sources stay separate from public inquiry forms and synthetic examples.

Boundary: Selected repositories and storage locations
Connection: Sources permitted for this workflow
Record: Source references and access context

Layer 4

Decide where inference runs.

Select a local model for the agreed workload. If a hosted endpoint is needed, approve that route separately and decide what data it may receive.

Boundary: Local runtime or approved hosted endpoint
Connection: Task input sent to the selected model
Record: Model, endpoint, and routing decision

Layer 5

Separate reading from taking action.

Set read and write permissions independently. Require human review for higher-risk actions such as exports or system changes.

Boundary: Allowed tools, targets, and network routes
Connection: A permitted action or a request for review
Record: Action, denial reason, reviewer decision

Layer 6

Decide what the team needs to retain.

Agree which prompts, outputs, source references, decisions, and logs to keep. Document where they are stored, who can read them, and when they are deleted.

Boundary: Agreed storage, access, and retention policy
Connection: Workflow records sent to customer-controlled storage
Record: Output, references, decisions, and task status

See the responsibility model

The request path

Request and authority

Capture the person, purpose, target system, and requested action. The harness’s shared security plane checks the proposed task against the approved scope before execution.

Sources and model route

All incoming and outgoing communications pass through the harness’s communication lane. The security plane enforces which sources and destinations each task may use, including its model route.

Tools and human review

Allow only configured actions. Hold writes, exports, or consequential outputs for the named reviewer where the workflow requires approval.

Output and records

Monitoring agents watch communications and policy activity 24/7. Store the approved output with its source references, route, and decision history so a reviewer can follow what happened.

Which parts of the system are local?

Inference, source storage, output storage, logs, backups, external tools, and support access are separate decisions. A model running on your infrastructure does not automatically make every connected service local. The architecture records each destination and any approved exception.

Where inference and retrieval execute.
Where prompts, files, outputs, and logs are stored.
Whether tools can reach external services and for what purpose.
Who can access the environment for administration or support.

What a bounded agent is allowed to do

Each agent needs a stated purpose and limits on sources, tools, destinations, execution time, and actions. Velociti’s harness uses one security plane to enforce these policies across its communication lane. Monitoring bots operate 24/7 to watch communications and policy activity. The implementation review sets the rules for your workflow and tests permitted and denied requests.

From architecture to an implementation decision

Your workflow owner supplies approved examples and criteria for checking the output. Your IT team provides the infrastructure and access context. We use those inputs to develop the implementation and test plan, then recommend whether to expand, revise, or stop after testing. Access and integration work determine the schedule.

Have a workflow in mind?

Tell us what it involves and which systems it uses.

Request an AI setup review