Background
We’ve been hard at work, developing the Noxus platform to make AI co-workers accessible to all enterprises, and everyone within each organization. To solve complex problems, we developed our no-code interface powered by an AI-Native orchestration engine ([link to blog post](link to blog post)).
Alongside this engine, our platform provides a full-stack experience designed to deliver AI in production and at scale: from observability and monitoring, governance, scalability and fault-tolerance, to guardrails, data management, and more. By building on top of our platform, you immediately benefit from these robust capabilities.
In the initial phases at Noxus, we focused primarily on bringing AI capabilities directly to business teams. Over time, we discovered that integrating at scale within large enterprises demands close cooperation between business and technical teams.
In this blog post, we’ll outline how we identified the growing need among technical teams and began developing the engine-sdk, starting by implementing a set of actions for a practical mock use-case. We'll follow up in future blog posts covering additional engine-sdk capabilities.
The Need
As we collaborated closely with technical departments on infrastructure and other technical matters, we began to notice unexpected curiosity about what powers our platform.
Technical teams were already actively building their own experiments, tools, and agents from scratch. When they saw Noxus deployed and running in production, showcasing robust use-cases and engine capabilities, it sparked a key question: could they also leverage our platform, without losing the flexibility and extensibility provided by custom coding?
Responding to this interest, we began focusing significantly on making our platform not only business-friendly but also developer-friendly—allowing teams to extend and customize Noxus through a high-code approach.
This journey began with the launch and ongoing expansion of our API for platform interaction. Today, we’re excited to introduce the next significant step forward: the Noxus Engine SDK.
The Noxus Engine SDK
Beyond creating co-workers, agents, flows, and other solutions, the true power of the Noxus platform comes from its build-once, use-everywhere approach. Everything we've developed consists of reusable components that describe interactions within the virtual world, usable across various flows, agents, data sources, and beyond.
To further amplify this power, we've created the Noxus Engine SDK. This SDK initially enables developers to extend all entities within the engine, including nodes, data sources, triggers, integrations, and models. In the coming months, we'll expand this capability to include direct modifications to the engine itself—but more on that in future posts.
And what better way to demonstrate the Noxus Engine SDK than to actually put it into action? For the rest of this post, we'll dive deeper into a technical example. Imagine you're working at Corp, which operates an internal customer complaint handling service, and you want to integrate this seamlessly with Noxus
Integrating Corp with Noxus
1. The Base Service
The service "complaints.corp.com" is a REST API that allows you to read and manage customer complaints.
GET /complaints - list all complaints
{"complaints": [
{
"id": "123",
"title": "Complaint title",
"description": "Complaint description"
}
]}
GET /complaints/{id} - get a specific complaint
{
"id": "123",
"title": "Complaint title",
"description": "Complaint description"
}
POST /complaints - create a new complaint
{
"id": "123",
"title": "Complaint title",
"description": "Complaint description"
}
The service takes an API key header: Authorization: Bearer <api_key>, and returns JSON responses.
2. Custom Nodes
One of the main components of the Noxus platform is the flow builder, which allows users to create complex processes by dividing it into a series of steps.
A node, or action, is a building block of a flow. By extending the library of nodes with the engine-sdk you provide that action as a possibility in a flow, for agents, for data source processing and so on.
Let's try to create a custom node that will allow users to read a specific complaint from the complaints service.
We start with a few python imports:
from noxus.nodes import (
Connector,
BaseNode,
ConfigDynamicText,
NodeConfiguration,
Parameter,
ExecutionContext,
TypeDefinition,
DataType,
)
import requests
Then we can create our custom node configuration, this configuration contains the possible switches and toggles you get when you click on our node in the workflow builder (for now we'll just hardcode the API key here, but in our next blog post we'll show how to improve this):
class ComplaintFetcherNodeConfig(NodeConfiguration):
api_key: str = Parameter(
default = "",
display= ConfigDynamicText(label='Complaints Service API key'),
)
Now we're ready to implement the brains behind this node:
class ComplaintFetcherNode(BaseNode[ComplaintFetcherNodeConfig]):
node_name = "ComplaintFetcherNode"
title = "Fetch a complaint"
color = "#E9F6EF"
image = "<https://example.com/complaint.png>"
description = "This module enables you to fetch a specific complaint from the complaints service."
small_description = "Fetch a specific complaint from the complaints service."
visible = True
config_class = ComplaintFetcherNodeConfig
inputs = [
Connector(
name = 'complaint_id',
label = 'Complaint ID',
definition = TypeDefinition(data_type=DataType.str, is_list=False),
optional = False,
)
]
outputs = [
Connector(
name = 'complaint_title',
label = 'Complaint Title',
definition = TypeDefinition(data_type=DataType.str, is_list=False)
optional = False,
),
Connector(
name = 'complaint_description',
label = 'Complaint Description',
definition = TypeDefinition(data_type=DataType.str, is_list=False)
optional = False,
)
]
def call(self, ctx: ExecutionContext, complaint_id: str) -> str:
'''
The arguments after ctx are passed automatically as the type and names of the inputs.
'''
resp = requests.get(
f"<https://complaints.corp.com/complaints/{complaint_id}>",
headers={"Authorization": f"Bearer {self.config.api_key}")
data = resp.json()
title = data['title']
desc = data['desc']
# the key must match the name in the outputs
return {"complaint_title": title,
"complaint_description": desc
}
3. Unleasing the plugin
Next up we need to register the plugin with the noxus platform at import time:
from noxus import Plugin, PluginOptions, register_plugin
class CorpPluginOptions(PluginOptions):
pass
class CorpPlugin(Plugin[CorpPluginOptions]):
def nodes(self):
return [ComplaintFetcherNode]
register_plugin(CorpPlugin)
If we now package this up in a python package, release it in a git repo or push it to pypi, and head over to the Noxus platform, add the plugin to https://<mynoxusurl>/admin/home/plugins (either with a git link or pypi) and enjoy running your new node!
