Brief Introduction to the Occam SDK
Last updated
Last updated
Occam is currently in invite only access as we scale our system. To start using Occam for developing automation applications, , or get in touch at .
Details of our architecture and product experience can be found at and .
Occam offers a comprehensive SDK for generating, running, modifying and supervising automations.
Our automation engine relies on the following key components
Resources catalogue: This is the set of APIs, models, tools and datasets that Occam natively supports or that you make available to the Occam automation engine.
Preferences: Guardrails, rules and limits the developer sets that the Occam engine will operate within (time limits, token limits etc)
Reasoning Engine: The component of our system responsible for coming up with automation plans to fulfil a specified goal. This component leverages a multi-agent planning architecture, that combines the resource catalogue, preferences and a specified business objective, to generate automation proposals that the you can modify, request modifications for or publish.
Run Manager: A distributed orchestration system used to run and monitor automation runs. It handles horizontal scalability, fault tolerance, and status updates. It also interfaces with our reasoning engine to enable runtime modifications to automation workflows.
Data Access and Manipulation layer: For accessing, querying and combining datasets. This supports a variety of dataset formats and sources, including APIs, filesystems, databases and automation run results, that we represent as datasets in their own right. The system was designed to enable writing single SQL queries that simultaneously speaks to these different formats. For example, you can write a query that reasons over data from an API in combination with one from a database.
Automation run results: Each step executed as part of a running automation plan is saved as a dataset (if you have designated that) and can be consumed by other steps in the run. Our system also produces run reports that allow you to inspect the outputs of intermediate steps, allows you to run your own analysis on the data or export it, and possibly guide run-time interventions.
The following sections describe the SDK capabilities Occam offers for developers to prototype, modify, run and supervise automations.
Creating an automation goal is fairly simple. All you need to do is specify the name of the goal and a list of messages describing the purpose of your automation. The goal is what will be used to drive the automation engine.
Once the goal is created, you can task our automation engine with creating a distributed automation workflow that can achieve your goal. The automation is a Direct Acyclic Graph that draws on all resources in your catalogue, whether datasets or tools, to sequence a set of steps to solve a problem.
Your resource catalogue includes Occam specialised tools, any files or databases or product integrations that you've connected to from the list we support (currently we support all the major enterprise product integrations covering finance, operations, sales, marketing and product work needs)
To create an automation, simply run
This triggers an automation generation process that you can poll the status for while it's running.
Which returns an enum for the different generation statuses of an automation
Once creation is completed, you can fetch the full automation payload using the automation graph endpoint.
automation_graph
will be a directed acyclic graph composed of nodes and field mappings.
Nodes: These can be runnable tools or datasets. The detail endpoint returns a number of node properties, including its node name, run parameters, parameter variable types, warnings and errors.
Field mappings: These represent field level edges between nodes. Our engine takes care of ensuring that connected fields are compatible or convertible to one another based on tightly specified input/output schemas, as well as field adaptation logic.
Below is an example of what automation_graph
looks like is shown in the simple example below, that searches the web for some terms, scrapes URLs produced by the search tool, and then counts the number of times a set of search phrases appear in the web-browsed content.
Automation plans can be modified in one of two ways. You can send your own modifications or you can ask the agents to perform modifications to an automation proposal.
You can submit modifications to automation proposals. These will get validated and applied to the automation. If a modification of yours maps outputs from one tool to an incompatible input of another tool, the reasoning engine will try to add an adapter that will transform that output. If it fails, it will still save your modifications but flag them as one with issues.
Here you inserted a human-in-the-loop between nodes 1 and 2, the human input will be provided to node 2, along with any other inputs node 2 was receiving.
Note: you can perform multiple modification request iterations, as needed.
Modification requests are expected to be a text message and can optionally also include a list of node ids that you would like to refer to when requesting the modifications.
We also support combining both, sending your own modifications to the plan for saving and validation, and requesting the agents to then perform further modifications, just as you would while working in a team, you make your own additions and ask for others' feedback.
Once you're happy with the automation proposal, you can publish it to your catalog, so you can request automation runs when you so choose.
Once your automation is ready, you can trigger a run. Automation runs are async. You can poll for status while they're executing, pause automation runs, request modifications while pausing, resume and abort automations.
To trigger an automation run:
Polling for run status
which is an enum with the following values
You can also get granular details about the run progress, status of individual nodes etc
which follows the same structure as automation detail, but with extra information like run_status
and node_runs
on each node object.
You can also pause running automations, this is an important feature in long running automations, where you might want to intervene with the run due to some unforeseen event, or to adjust the automation half-way through.
The status shown above can be polled to see if the plan is Pausing
or Paused
. While pausing or paused, we support runtime automation modification requests that you can ask our reasoning agents to make. At present, we don't support users submitting their own modifications to a running plan, only ask agents to perform modifications.
The automation can be resumed with or without a modification request.