You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ Graphite is a flexible, event-driven framework for building AI agents using modu
19
19
By treating events as the single source of truth, Graphite automatically logs every state change and decision path. This level of detailed recordkeeping is indispensable for users working in regulated sectors or who need full traceability for debugging and compliance.
20
20
21
21
4.**Restorability**
22
-
Long-running AI tasks risk substantial rework if they fail mid-execution. In Graphite, checkpoints and event-based playback enable workflows to resume from the precise point of interruption, minimizing downtime and maximizing resource efficiency ([Example](/tests_integration/react_assistant/react_assistant_recovery_example.py)).
22
+
Long-running AI tasks risk substantial rework if they fail mid-invoke. In Graphite, checkpoints and event-based playback enable workflows to resume from the precise point of interruption, minimizing downtime and maximizing resource efficiency ([Example](/tests_integration/react_assistant/react_assistant_recovery_example.py)).
23
23
24
24
Graphite is based on:
25
25
@@ -43,7 +43,7 @@ Graphite is structured into three conceptual layers — *Assistants*, *Nodes*, a
43
43
44
44
-**Assistants**: High-level orchestration layer that manages AI agent workflows and user interactions. Assistants handle the complete lifecycle of requests, from initial input to final response.
45
45
-**Nodes**: A node is a discrete component in a graph-based agent system that operates under an event-driven model. Its primary role is to represent its position within a workflow graph, manage event subscriptions, and designate topics for publishing.
46
-
-**Tools**: In our platform, tools represent the execution components within a workflow. A Tool is essentially a function designed to transform input data into output based on specified rules or logic.
46
+
-**Tools**: In our platform, tools represent the invoke components within a workflow. A Tool is essentially a function designed to transform input data into output based on specified rules or logic.
47
47
-**Workflow**: Orchestrates interactions among nodes using a Pub/Sub pattern with in-memory message queuing.
@@ -53,11 +53,11 @@ Additionally, Graphite offers modules that support essential architectural patte
53
53
-**Event**: Core to Graphite’s event-driven architecture. Events represent every state change, stored in a durable event store, serving as the single source of truth for downstream processing, auditing, workflow restoration, and more.
54
54
-**Topic**: Implements lightweight FIFO message queuing, essential for Pub/Sub interactions.
55
55
-**Command**: Implements the Command pattern, clearly separating request initiators from executors through defined Command objects and handlers. Commands carry all necessary context, allowing nodes to invoke tools independently and cleanly.
56
-
-**Decorators**: Automatically capture execution details (inputs, outputs, and errors) as events without altering core business logic, facilitating auditability and traceability.
57
-
-**Execution Context**: Manages identifiers across message life cycles:
58
-
-`conversation_id`: Manages conversations, which may include multiple executions.
56
+
-**Decorators**: Automatically capture invoke details (inputs, outputs, and errors) as events without altering core business logic, facilitating auditability and traceability.
57
+
-**Invoke Context**: Manages identifiers across message life cycles:
58
+
-`conversation_id`: Manages conversations, which may include multiple invokes.
59
59
-`assistant_request_id`: Tracks requests at the assistant level, facilitating complex multi-node workflows.
60
-
-`execution_id`: Handles individual user requests, potentially involving multiple assistants in complex scenarios.
60
+
-`invoke_id`: Handles individual user requests, potentially involving multiple assistants in complex scenarios.
61
61
-`user_id`: Identifies individual users, supporting multiple conversations per user.
62
62
63
63
For more details, visit the Graphite [documentation](https://binome-dev.github.io/graphite/).
Copy file name to clipboardExpand all lines: assets/overall-design.excalidraw
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -8540,11 +8540,11 @@
8540
8540
"locked": false,
8541
8541
"fontSize": 20,
8542
8542
"fontFamily": 1,
8543
-
"text": "Each node in the directed graph aggregates the data from all of \nits ancestor nodes—i.e., any nodes from which it can be reached by \nfollowing the graph’s edges backward—so that when the node executes, \nit has the complete set of data from every path leading into it.",
8543
+
"text": "Each node in the directed graph aggregates the data from all of \nits ancestor nodes—i.e., any nodes from which it can be reached by \nfollowing the graph’s edges backward—so that when the node invokes, \nit has the complete set of data from every path leading into it.",
8544
8544
"textAlign": "left",
8545
8545
"verticalAlign": "top",
8546
8546
"containerId": null,
8547
-
"originalText": "Each node in the directed graph aggregates the data from all of \nits ancestor nodes—i.e., any nodes from which it can be reached by \nfollowing the graph’s edges backward—so that when the node executes, \nit has the complete set of data from every path leading into it.",
8547
+
"originalText": "Each node in the directed graph aggregates the data from all of \nits ancestor nodes—i.e., any nodes from which it can be reached by \nfollowing the graph’s edges backward—so that when the node invokes, \nit has the complete set of data from every path leading into it.",
Copy file name to clipboardExpand all lines: docs/docs/getting-started/features.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,8 +2,8 @@
2
2
3
3
The core design principles that set Graphite apart from other agent frameworks are:
4
4
5
-
1.**A Simple 3-Layer Execution Model**
6
-
Three distinct layers—assistant, node, and tool—manage execution, while a dedicated workflow layer oversees orchestration.
5
+
1.**A Simple 3-Layer Invoke Model**
6
+
Three distinct layers—assistant, node, and tool—manage invoke, while a dedicated workflow layer oversees orchestration.
7
7
8
8
2.**Pub/Sub Event-Driven Orchestration**
9
9
Communication relies on publishing and subscribing to events, ensuring a decoupled, modular flow of data throughout the system.
@@ -23,34 +23,34 @@ Combining these elements, **Graphite** provides a production-grade AI applicatio
23
23
By treating events as the single source of truth, Graphite automatically logs every state change and decision path. This level of detailed recordkeeping is indispensable for users working in regulated sectors or who need full traceability for debugging and compliance.
24
24
25
25
4.**Restorability**
26
-
Long-running AI tasks risk substantial rework if they fail mid-execution. In Graphite, checkpoints and event-based playback enable workflows to resume from the precise point of interruption, minimizing downtime and maximizing resource efficiency.
26
+
Long-running AI tasks risk substantial rework if they fail mid-invoke. In Graphite, checkpoints and event-based playback enable workflows to resume from the precise point of interruption, minimizing downtime and maximizing resource efficiency.
27
27
28
28
Together, these capabilities—observability, idempotency, auditability, and restorability—distinguish **Graphite** as a framework for building robust and trustworthy AI applications. Below is a detailed breakdown of how Graphite implements each feature.
29
29
30
30
## Observability
31
31
32
-
The system leverages event sourcing to record all operations, combined with OpenTelemetry for standardized tracing. Thanks to the clearly defined three-layer execution model (assistant, node, tool) plus an orchestration workflow, each execution function is decorated to capture inputs, outputs, and any exceptions. These captures are converted into events (stored in the event store) and traces (exported to platforms like Arize or other OpenTelemetry services).
32
+
The system leverages event sourcing to record all operations, combined with OpenTelemetry for standardized tracing. Thanks to the clearly defined three-layer invoke model (assistant, node, tool) plus an orchestration workflow, each invoke function is decorated to capture inputs, outputs, and any exceptions. These captures are converted into events (stored in the event store) and traces (exported to platforms like Arize or other OpenTelemetry services).
33
33
34
-
Meanwhile, each Topic instance logs pub/sub interactions in the event store after processing. Coupled with the ExecutionContext object, this approach makes the entire data flow within the agentic workflow fully transparent. Because every node and tool has a unique name and ID, and each operation is stamped with execution context IDs, locating specific inputs and outputs is straightforward. Then given pub/sub events, the framework can build a directed data flows between nodes. Even there are circles, the data flow can form a DAG with publishing and consuming offset in each topic.
34
+
Meanwhile, each Topic instance logs pub/sub interactions in the event store after processing. Coupled with the InvokeContext object, this approach makes the entire data flow within the agentic workflow fully transparent. Because every node and tool has a unique name and ID, and each operation is stamped with invoke context IDs, locating specific inputs and outputs is straightforward. Then given pub/sub events, the framework can build a directed data flows between nodes. Even there are circles, the data flow can form a DAG with publishing and consuming offset in each topic.
35
35
36
36
## Idempotency
37
37
38
38
Graphite adopts an event-driven architecture where topics function as logical message queues, storing each event exactly once in an event store. When a workflow fails, needs to be retried, or is paused (e.g., for a human-in-the-loop intervention), it can resume from the last known valid state by replaying events that were produced but not yet consumed by downstream nodes.
39
39
40
-
Consumption events are only recorded once the entire node processing completes successfully. Until that point, the system treats partial or failed node executions as if they never happened, preventing duplicated outputs or broken states. Should a node encounter an error (e.g., an LLM connection failure, external API issue, or function exception), Graphite detects the unconsumed events upon restoration and places the associated node(s) back into the execution queue. This design ensures the node can safely retry from the same input without creating conflicting or duplicated consumption records.
40
+
Consumption events are only recorded once the entire node processing completes successfully. Until that point, the system treats partial or failed node invokes as if they never happened, preventing duplicated outputs or broken states. Should a node encounter an error (e.g., an LLM connection failure, external API issue, or function exception), Graphite detects the unconsumed events upon restoration and places the associated node(s) back into the invoke queue. This design ensures the node can safely retry from the same input without creating conflicting or duplicated consumption records.
41
41
42
42
By storing each event exactly once and withholding consumption records until success, Graphite guarantees idempotent behavior. Even if a node issues multiple invocations due to an error, the event logs and consumption rules still reconstruct a single, consistent path from invocation to response. This approach produces correct outcomes on retries while maintaining a complete, conflict-free audit trail.
43
43
44
44
## Auditability
45
45
46
-
Auditability in Graphite emerges naturally from its observability. By automatically persisting all execution events and pub/sub events in a centralized event store, the platform provides a complete historical record of every action taken. Function decorators capture each execution (including inputs, outputs, and exceptions), while Topic operations log every publish and consume operation, and effectively acting as a “cache” layer of orchestration events.
46
+
Auditability in Graphite emerges naturally from its observability. By automatically persisting all invoke events and pub/sub events in a centralized event store, the platform provides a complete historical record of every action taken. Function decorators capture each invoke (including inputs, outputs, and exceptions), while Topic operations log every publish and consume operation, and effectively acting as a “cache” layer of orchestration events.
47
47
48
48
Moreover, Graphite’s modular design and clear separation of concerns simplify the process of examining specific components—such as an LLM node and its associated tool. Each module has well-defined responsibilities, ensuring that every action is accurately documented in the event store and easily traceable. This end-to-end audit trail not only supports today’s nascent AI regulations but positions Graphite to adapt to evolving compliance requirements. By preserving all relevant data in a consistent, verifiable format, Graphite provides the transparency and accountability that organizations demand from AI solutions.
49
49
50
50
## Restorability
51
51
52
52
Restorability in Graphite builds on top of idempotency, ensuring that whenever a workflow stops—due to an exception, human intervention, or any other cause—it always concludes at a point where an event has been successfully published. This guarantees that upon resuming the workflow for an unfinished assistant_request_id, any node subscribed to that newly published event is reactivated, effectively restarting the process from where it left off.
53
53
54
-
Internally, Graphite uses offset-based consumption in each topic. Whenever a node publishes an event (including self-loops or circular dependencies), the system records the publish offset in `PublishToTopicEvent` instance. When a node later consumes that event, it updates a corresponding consumption offset in topic, and store the offset in `ConsumeFromTopicEvent`. If a workflow is interrupted before consumption offsets are written, the node remains subscribed to the “unconsumed” event. As a result, when the workflow recovers, the engine identifies these outstanding events and places the node(s) back into the execution queue.
54
+
Internally, Graphite uses offset-based consumption in each topic. Whenever a node publishes an event (including self-loops or circular dependencies), the system records the publish offset in `PublishToTopicEvent` instance. When a node later consumes that event, it updates a corresponding consumption offset in topic, and store the offset in `ConsumeFromTopicEvent`. If a workflow is interrupted before consumption offsets are written, the node remains subscribed to the “unconsumed” event. As a result, when the workflow recovers, the engine identifies these outstanding events and places the node(s) back into the invoke queue.
55
55
56
56
This mechanism effectively transforms cyclical or looping dependencies into a directed acyclic graph. The event store, combined with offset tracking, reveals which events have been fully processed and which remain pending, letting Graphite re-trigger only the incomplete parts of the workflow. The result is a resilient system that can resume from exactly where it stopped—without reprocessing entire segments or risking inconsistent states.
Copy file name to clipboardExpand all lines: docs/docs/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
**Graphite** is an open-source framework for creating **domain-specific AI assistants** via composable, agentic workflows. It emphasizes loose coupling and well-defined interfaces, enabling developers to construct flexible, modular systems. Each major layer – **assistant, node, tool,** and **workflow** – has a clear role in orchestrating or executing tasks, with events serving as the single source of truth for every state change or data exchange.
4
4
5
-
This documentation details how **Graphite’s event-driven architecture** seamlessly supports complex business logic, from initial user requests through advanced tool integrations (e.g., LLM calls, function calls, RAG retrieval). Dedicated topics manage pub/sub operations, providing mechanisms for input, output, and human-in-the-loop interactions. Meanwhile, commands encapsulate execution logic for each tool, allowing nodes to delegate work without tight coupling.
5
+
This documentation details how **Graphite’s event-driven architecture** seamlessly supports complex business logic, from initial user requests through advanced tool integrations (e.g., LLM calls, function calls, RAG retrieval). Dedicated topics manage pub/sub operations, providing mechanisms for input, output, and human-in-the-loop interactions. Meanwhile, commands encapsulate invoke logic for each tool, allowing nodes to delegate work without tight coupling.
6
6
7
7
Four critical capabilities—**observability, idempotency, auditability,** and **restorability**—underpin Graphite’s suitability for production AI environments. Observability is achieved via event sourcing and OpenTelemetry-based tracing, idempotency through carefully managed event stores and retry logic, auditability by logging every action and data flow, and restorability by maintaining offset-based consumption records that let workflows resume exactly where they left off.
0 commit comments