Blog
Published By Mia Wagner

Orpius Events: Turning Signals into Autonomous Work

If you want AI agents to be more than chatbots, you need a way to connect real-world signals to real work. A payment clears. A sensor trips. A customer signs a contract. A nightly reconciliation finishes. In most systems, those are just logs or webhook payloads. In Orpius, they can become agentic execution.

Orpius Events are the platform’s trigger mechanism: a named event represents a meaningful occurrence, and when it is raised it launches one or more activities inside a space. Those activities are not rigid scripts. They are instructions given to an agent operating within Orpius’ secure boundary, with access to the tools and permissions you choose. That means an event can initiate analysis, coordination, follow-up actions, notifications, tool calls, and further delegation.

An Event is therefore not merely a webhook endpoint. It is a bridge between the outside world (and between internal Orpius workflows) and autonomous, auditable activity execution.

Below is how Events work, how they are raised internally and externally, how parameters are passed, and how you can use Events as the backbone of “grand” multi-agent, multi-model orchestration.

What an Orpius Event is (and what it is not)

An Event in Orpius is:

  • A registered identifier in a space (for example, FactoryUnitArrived).
  • A trigger point that can be raised from outside Orpius via HTTPS, or from inside Orpius by name using the EventTrigger tool.
  • A container for activities: one event can execute one or many activities, each defined by a title and natural-language instructions.
  • A security boundary and delegation mechanism: events can be used to separate untrusted triggers from privileged execution.

An Event is not:

  • A hardcoded workflow definition.
  • A single “handler function” you must implement and deploy.
  • A mere notification primitive.

Instead, it is an orchestration primitive designed for autonomy: “when X happens, do Y”, where Y can include tool calls, code execution, file operations, notifications, web retrieval, follow-up events, or even calling operations handled by other agents.

The big picture: events trigger agentic activities

In Orpius, activities are the unit of non-interactive work. Activities can be triggered by schedules or by events, and are handled by an agent selected by Orpius based on permissions, tools, and profile suitability. Once executed, the outcome is verified by an internal audit step, producing a simple verdict (“Yes” or “No”) and preserving artefacts for later review.

That lifecycle matters because it means events are not “fire and forget” webhooks. They are “fire and orchestrate”, with supervision, logging, and verification built in.

In practice:

  1. An event is raised (externally or internally).
  2. Orpius places the resulting activity or activities into its activity queue.
  3. A suitable agent is selected to execute each activity.
  4. The agent runs the instructions, using permitted tools as needed.
  5. The outcome is recorded and audited.

The result is a platform where triggering is easy, but execution remains controlled and observable.

Creating an Event: chat-first, but fully configurable

Orpius supports two practical ways to create events:

1) Create via chat (the fast way)

Because the Orpius Console is chat-driven and understands the system itself, you can simply instruct it to create an event and its initial activities.

Example:

“Create an event named FactoryUnitArrived that notifies the user robertB with the order details.”

Orpius can register the event, create an activity, and include details like usernames where required, then you can inspect and refine it in the Events view.

This is a subtle but important productivity feature: you do not need to open a separate configuration UI to “wire” automation. You can describe the automation and then tweak it.

2) Create manually (the explicit way)

Manual creation is straightforward:

  • Register the event name in the Events view.
  • Add one or more “Event Triggered Work” items (activities), each with a title and instructions.
  • Optionally grant relevant custom tools that can be used during execution.

This is the same end state as chat creation, just done explicitly.

Triggering an Event: internal by name, external by HTTPS

Orpius Events are designed to be triggered in two distinct ways. This duality is where things get interesting.

flowchart TB
  ext[External system<br/>App / webhook / sensor] -->|HTTPS GET or POST<br/>Event ID + Access Key| ev[Orpius Event<br/>Registered in a Space]

  subgraph space[Orpius Space]
    ev --> act1[Activity A<br/>Instructions]
    ev --> act2[Activity B<br/>Instructions]
    act1 --> agent1[Agent executes<br/>selected by Orpius]
    act2 --> agent2[Agent executes<br/>selected by Orpius]
    agent1 --> tools[Tools<br/>Notifier / Web / Code / Custom]
    agent2 --> tools
    agent1 -->|EventTrigger tool| ev2[Follow-up Event]
    ev2 --> act3[Activity C]
  end

Internal triggering (inside a space)

Internal triggering uses the EventTrigger tool to raise an event by name. Any eligible origin can do this:

  • an event activity
  • a scheduled activity
  • an operation
  • an interactive chat

So an agent can be executing work, detect a condition, and trigger another event to kick off follow-up activities. This is the simplest way to chain behaviours without building a complicated central workflow definition.

Example pattern:

  • Event MotionDetected runs a quick triage activity.
  • If triage finds something important, it triggers SecurityAlertRaised.
  • That second event runs a different activity that notifies the right people and stores evidence.

This is agentic composition: small, named triggers coordinating larger behaviours.

External triggering (from any system)

External triggering happens over HTTPS. Each event has a unique endpoint, and Orpius provides two access keys so you can rotate credentials without downtime.

A typical endpoint shape looks like:

https://<tenant>.app.orpius.com/api/v1/event/raise?event-id=<id>

When called via HTTP GET or POST, Orpius raises the event and kicks off its activities.

This means you can connect Orpius to:

  • your application (customer actions, internal admin actions, business milestones)
  • infrastructure (monitoring systems, alerts, CI/CD notifications)
  • physical-world signals (cameras, sensors, manufacturing equipment)
  • third-party SaaS (webhooks from payment processors, CRMs, ticket systems)

But you are not limited to “notify someone”. You can trigger autonomous handling with tools and follow-up events.

Events as an internal orchestration bus

The “grand” part of Orpius Events is that they don’t just connect external systems to Orpius. They also connect Orpius activities to other Orpius activities.

Events become your internal event bus for agentic work.

That enables patterns like:

Fan-out execution

A single event can have multiple activities, which can be executed independently:

  • One activity writes an incident record to storage.
  • Another notifies a human.
  • Another triggers a follow-up operation to gather more evidence.
  • Another creates a summary report.

You gain the ability to split responsibilities, and each activity can be phrased for the type of agent/model that is best suited for it.

Escalation chains

A “soft” event can trigger a “hard” event only when conditions justify it:

  • InvoiceReceived triggers extraction and validation.
  • If validation fails, the agent triggers InvoiceException.
  • InvoiceException triggers a more privileged workflow (such as notifying finance, requesting human approval, or updating systems).

State machine by events

Instead of building a big workflow engine graph, you can model stages as events:

  • OrderPlaced
  • OrderVerified
  • OrderPacked
  • OrderShipped
  • OrderDelivered

Each stage runs its own activities and triggers the next event when ready. You get modularity, and you can evolve each stage without rewriting a monolithic workflow.

Multi-agent collaboration

Even when events are currently handled by built-in agents, you can still treat each activity as a delegated unit of work. And in Orpius generally, different agents can be configured with different models, personalities, and tool permissions. The point is that events give you a clean, explicit trigger surface that can be used to route work to the right kind of execution context.

Events and segregation of duties: safe delegation to higher-trust agents

One of the most practical uses of Events is security and control.

In Orpius, operations exposed to external callers are deliberately locked down: tools are disabled by default because some tools are too powerful for customer-facing contexts (file access, scheduling, team notifications, and so on). That is least privilege applied properly.

flowchart TB
  caller[External caller<br/>Customer app / third-party webhook]
  op[Customer-facing Operation<br/>Restricted tools]
  ev[Event boundary<br/>Named + auditable]
  act[Event activities]
  agent[Privileged agent context<br/>Full-trust tools as needed]
  tools[Tools<br/>Storage / Notifier / Scheduler / Custom]

  caller -->|HTTPS + Access Key| op
  op -->|Raises event| ev
  ev --> act
  act --> agent
  agent --> tools

  opNote[(Least privilege<br/>No storage, no scheduling<br/>No team awareness by default)]
  op -.-> opNote

Events provide a clean way to keep that boundary while still enabling powerful automation:

  • A customer-facing operation can do lightweight processing and then raise an event.
  • The event’s activities run under a more privileged agent context, with the tools and permissions needed to complete the work.

This gives you segregation of duties in an agentic system:

  • Untrusted inputs can request actions, but cannot directly perform sensitive actions.
  • Trusted internal activities can validate, enrich, and then act.

It also makes your system easier to reason about. The event itself becomes the “handover” point where the context changes from “external caller” to “internal execution”.

Passing parameters: events as structured triggers, not just signals

A trigger without context is mostly noise. Orpius Events explicitly support parameter passing, and this is where events become a powerful integration surface.

Parameters in GET requests

When triggering an event via HTTP GET:

  • Query string keys prefixed with an underscore (_) are passed to tools only.
  • Query string keys without the underscore are passed to tools and the agent.

This is a deceptively strong design decision because it lets you control what the model sees.

Examples:

  • You might pass _customerId=123 so tools can fetch details, but the agent does not receive the raw customer ID directly.
  • You might pass orderNumber=SO-91823 so the agent can reason and communicate using a human-friendly identifier.

In other words, you can design event triggers that are both useful and privacy-conscious.

Parameters in POST requests

When using HTTP POST:

  • Key/value pairs are provided to tools through the tool context object.
  • Additionally, raw JSON can be passed directly to the agent in the body.

This gives you a practical gradient of options:

  • Minimal payload: just an identifier and let tools fetch the details.
  • Full context: include the full JSON record if you want the agent to reason over it directly.
  • Mixed approach: provide rich context to tools, and a curated subset to the agent.

That’s how events become “structured triggers”. You are not limited to “run this instruction”. You can pass the facts needed for an agent to act well.

Different agents, different models, different work: chaining activity types

A core strength of Orpius is that it supports multiple models and multiple agents, and it treats them as configurable execution resources. In real systems, you often want different models for different tasks:

  • A lower-cost model for routine classification or triage.
  • A more capable model for complex reasoning or high-stakes communication.
  • A specialist model for extraction, translation, or code generation.
  • A constrained agent persona for customer-facing responses.
  • A higher-trust internal agent for privileged actions.

Events are what let you stitch those together cleanly.

One good mental model is:

  • Event = the “what happened”
  • Activity = the “what should be done”
  • Agent + Model = the “who should do it, and how capable should they be”
  • Tools = the “how it interacts with reality”

Then chaining events gives you a modular system of delegated work where each step can run under a different capability profile.

Concrete example: a monitoring workflow with follow-up events

Here is a realistic pattern (similar to the monitoring example in the guide), expressed as an event-driven chain:

Event: MotionDetected

Activities:

  1. “Snap an image from camera X and classify what triggered motion. If it is irrelevant (shadows, animals), record it and stop.”
  2. “If a person is detected, trigger PersonDetected and pass the confidence score and camera identifier.”

Event: PersonDetected

Activities:

  1. “Use ImageAnalysis again but with a stricter prompt to determine whether this is an authorised person (uniform, badge, time-of-day rules).”
  2. “If suspicious, trigger SecurityAlert with a short summary and a link to the stored image.”

Event: SecurityAlert

Activities:

  1. “Notify the on-call person and include a plain English summary.”
  2. “Write an incident report file to storage.”
  3. “If high severity, call an internal operation to initiate a phone call tree or integration with a ticketing system.”

None of this requires you to pre-implement a bespoke workflow engine. You just define events and activities, then let Orpius handle execution, tool calls, supervision, and auditing.

Why this matters: events make autonomy operational

If you step back, Orpius Events are the difference between:

  • an AI assistant you have to poke repeatedly, and
  • an AI execution layer that participates in real operations.

Events are how external systems and internal workflows can “summon” autonomous work at the right moment, with the right constraints, and with the right audit trail.

They also keep things legible. Instead of burying automation logic inside one sprawling agent prompt, you can create named events that reflect business concepts. That gives you:

  • clearer operational intent
  • easier debugging (you can inspect event activities)
  • safer delegation (events as handover points)
  • composability (events triggering events)
  • and smoother evolution over time (add activities, split events, tighten parameters, rotate keys)

And yes, it is rather grand: you end up with a system where occurrences become triggers, triggers become activities, activities become tool-enabled work, and the whole thing can cascade across agents, models, spaces, or even systems.

Practical tips for designing effective event-driven agentic systems in Orpius

  1. Name events after real-world meanings Prefer PaymentReceived over Webhook1.

  2. Keep activities single-purpose If one activity’s instructions become long and multi-stage, split it into multiple activities or multiple events.

  3. Use parameters carefully Put sensitive identifiers behind underscore-prefixed keys when you want tools to see them but not the agent.

  4. Treat events as trust boundaries If an external caller should not be allowed to schedule tasks or access storage, let them trigger an event that delegates to a more privileged internal activity.

  5. Chain events for escalation “Detect -> verify -> act” works well as event stages.

  6. Lean on auditing The audit verdict and logs are part of what makes autonomy operational rather than chaotic.

Closing thought

In Orpius, Events are not an afterthought. They are the platform’s connective tissue: the mechanism that turns signals into autonomous execution, and individual actions into composable, secure systems.

You can start with a single external event that sends a notification. But the moment you begin chaining events, passing parameters, separating trust levels, and delegating between activity types, you start building something more interesting: an agentic runtime where real work happens because the world changes, not because someone remembered to prompt a chatbot.

If you want Orpius to feel like infrastructure (more like connecting to a DBMS than embedding an AI library), Events are one of the key reasons: they give your applications, your agents, and your operations a shared, explicit language for “something happened, now do the right thing”.