sploink 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- sploink-0.1.0/.gitignore +11 -0
- sploink-0.1.0/LICENSE +21 -0
- sploink-0.1.0/PKG-INFO +229 -0
- sploink-0.1.0/PRD.md +373 -0
- sploink-0.1.0/README.md +178 -0
- sploink-0.1.0/pyproject.toml +73 -0
- sploink-0.1.0/sploink/__init__.py +5 -0
- sploink-0.1.0/sploink/architecture.py +694 -0
- sploink-0.1.0/sploink/canvas.py +634 -0
- sploink-0.1.0/sploink/classify.py +42 -0
- sploink-0.1.0/sploink/dashboard.py +464 -0
- sploink-0.1.0/sploink/graph.py +103 -0
- sploink-0.1.0/sploink/pricing.py +48 -0
- sploink-0.1.0/sploink/report.py +288 -0
- sploink-0.1.0/sploink/route.py +507 -0
- sploink-0.1.0/sploink/router.py +37 -0
- sploink-0.1.0/sploink/substrates/__init__.py +0 -0
- sploink-0.1.0/sploink/trace.py +193 -0
- sploink-0.1.0/sploink/workflow.py +54 -0
- sploink-0.1.0/sploink/wrap.py +526 -0
sploink-0.1.0/.gitignore
ADDED
sploink-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Tim Nguyen
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
sploink-0.1.0/PKG-INFO
ADDED
|
@@ -0,0 +1,229 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: sploink
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Heterogeneous compute routing for AI agent workflows.
|
|
5
|
+
Project-URL: Homepage, https://github.com/S-3-ai/sploink
|
|
6
|
+
Project-URL: Documentation, https://s-3-ai.github.io/sploink
|
|
7
|
+
Project-URL: Repository, https://github.com/S-3-ai/sploink
|
|
8
|
+
Project-URL: Issues, https://github.com/S-3-ai/sploink/issues
|
|
9
|
+
Author-email: Tim Nguyen <timothyng04@gmail.com>
|
|
10
|
+
License: MIT
|
|
11
|
+
License-File: LICENSE
|
|
12
|
+
Keywords: agent,anthropic,groq,inference,llm,observability,ollama,routing
|
|
13
|
+
Classifier: Development Status :: 3 - Alpha
|
|
14
|
+
Classifier: Intended Audience :: Developers
|
|
15
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
16
|
+
Classifier: Operating System :: OS Independent
|
|
17
|
+
Classifier: Programming Language :: Python :: 3
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
19
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
20
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
21
|
+
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
|
|
22
|
+
Classifier: Topic :: Software Development :: Libraries :: Python Modules
|
|
23
|
+
Requires-Python: >=3.11
|
|
24
|
+
Requires-Dist: pydantic>=2.6
|
|
25
|
+
Provides-Extra: all
|
|
26
|
+
Requires-Dist: anthropic>=0.40; extra == 'all'
|
|
27
|
+
Requires-Dist: groq>=0.11; extra == 'all'
|
|
28
|
+
Requires-Dist: ollama>=0.6.2; extra == 'all'
|
|
29
|
+
Requires-Dist: openai>=1.50; extra == 'all'
|
|
30
|
+
Requires-Dist: together>=2.14.0; extra == 'all'
|
|
31
|
+
Provides-Extra: anthropic
|
|
32
|
+
Requires-Dist: anthropic>=0.40; extra == 'anthropic'
|
|
33
|
+
Provides-Extra: bench
|
|
34
|
+
Requires-Dist: anthropic>=0.40; extra == 'bench'
|
|
35
|
+
Requires-Dist: datasets>=4.8.5; extra == 'bench'
|
|
36
|
+
Requires-Dist: groq>=0.11; extra == 'bench'
|
|
37
|
+
Requires-Dist: ollama>=0.6.2; extra == 'bench'
|
|
38
|
+
Requires-Dist: python-dotenv>=1.0; extra == 'bench'
|
|
39
|
+
Provides-Extra: dev
|
|
40
|
+
Requires-Dist: httpx>=0.27; extra == 'dev'
|
|
41
|
+
Requires-Dist: pytest>=8.0; extra == 'dev'
|
|
42
|
+
Provides-Extra: groq
|
|
43
|
+
Requires-Dist: groq>=0.11; extra == 'groq'
|
|
44
|
+
Provides-Extra: ollama
|
|
45
|
+
Requires-Dist: ollama>=0.6.2; extra == 'ollama'
|
|
46
|
+
Provides-Extra: openai
|
|
47
|
+
Requires-Dist: openai>=1.50; extra == 'openai'
|
|
48
|
+
Provides-Extra: together
|
|
49
|
+
Requires-Dist: together>=2.14.0; extra == 'together'
|
|
50
|
+
Description-Content-Type: text/markdown
|
|
51
|
+
|
|
52
|
+
# sploink
|
|
53
|
+
|
|
54
|
+
**Heterogeneous compute routing for AI agent workflows.**
|
|
55
|
+
|
|
56
|
+
Sploink intercepts LLM calls inside your agent code, classifies each call by step type
|
|
57
|
+
(classify, rerank, extract, reason, verify, ...), and routes each call to the most
|
|
58
|
+
appropriate compute substrate — edge (Ollama), LPU (Groq), GPU (Together), or
|
|
59
|
+
frontier API (Anthropic/OpenAI). Same agent code, different per-step compute placement.
|
|
60
|
+
|
|
61
|
+
> **Status:** Pre-MVP. The interception/observability layer works for Anthropic, Groq,
|
|
62
|
+
> OpenAI, Together, and Ollama. The router currently uses a static rule table; learned
|
|
63
|
+
> routing is on the roadmap. See [`PRD.md`](./PRD.md) for the full thesis.
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## Why
|
|
68
|
+
|
|
69
|
+
A multi-step agent workflow (e.g. RAG, multi-hop QA, document analysis) has 5–20
|
|
70
|
+
distinct LLM calls per request. Each step has a different compute profile: a
|
|
71
|
+
50-token classification doesn't need a frontier model — but the final reasoning
|
|
72
|
+
step might. Today, most agents route every call to a single closed-API model and
|
|
73
|
+
overpay 3–10× on the cheap steps.
|
|
74
|
+
|
|
75
|
+
Sploink fixes that by routing **per step** based on the step's actual demands.
|
|
76
|
+
|
|
77
|
+
## Install
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
# Core install (just the routing/observability layer)
|
|
81
|
+
pip install sploink
|
|
82
|
+
|
|
83
|
+
# With specific substrate SDKs:
|
|
84
|
+
pip install "sploink[anthropic]"
|
|
85
|
+
pip install "sploink[groq]"
|
|
86
|
+
pip install "sploink[ollama]"
|
|
87
|
+
|
|
88
|
+
# Everything:
|
|
89
|
+
pip install "sploink[all]"
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## Quickstart — observability mode
|
|
93
|
+
|
|
94
|
+
The simplest thing sploink does is observe every LLM call your agent makes and
|
|
95
|
+
record a structured trace.
|
|
96
|
+
|
|
97
|
+
```python
|
|
98
|
+
import sploink
|
|
99
|
+
from anthropic import Anthropic
|
|
100
|
+
|
|
101
|
+
sploink.wrap() # one line — patches every supported SDK
|
|
102
|
+
|
|
103
|
+
client = Anthropic()
|
|
104
|
+
# ... your existing agent code, unchanged ...
|
|
105
|
+
client.messages.create(
|
|
106
|
+
model="claude-haiku-4-5",
|
|
107
|
+
max_tokens=20,
|
|
108
|
+
messages=[{"role": "user", "content": "is this spam? 'You won!'"}],
|
|
109
|
+
)
|
|
110
|
+
client.messages.create(
|
|
111
|
+
model="claude-sonnet-4-6",
|
|
112
|
+
max_tokens=300,
|
|
113
|
+
messages=[{"role": "user", "content": "explain why in detail"}],
|
|
114
|
+
)
|
|
115
|
+
|
|
116
|
+
sploink.trace.print_summary()
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Output:
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
workflow 9f2c... | 2 calls | $0.0034 | 2400 ms
|
|
123
|
+
tokens: in=80 out=420
|
|
124
|
+
by step:
|
|
125
|
+
classify 1x $0.0001 200ms
|
|
126
|
+
reason 1x $0.0033 2200ms
|
|
127
|
+
by hardware:
|
|
128
|
+
frontier_api 2x $0.0034
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
Every call is also persisted to `~/.sploink/traces/<workflow_id>.jsonl` for offline
|
|
132
|
+
analysis with `python -m sploink.report` or `python -m sploink.canvas`.
|
|
133
|
+
|
|
134
|
+
## Quickstart — routing mode
|
|
135
|
+
|
|
136
|
+
Once you've observed your traces and confirmed step types look right, flip on
|
|
137
|
+
routing to redirect cheap steps to local Ollama (or any substrate you configure):
|
|
138
|
+
|
|
139
|
+
```python
|
|
140
|
+
import sploink
|
|
141
|
+
|
|
142
|
+
sploink.wrap()
|
|
143
|
+
sploink.enable_routing()
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
The default v0 rules (in [`sploink/router.py`](./sploink/router.py)) route
|
|
147
|
+
classify/rerank/extract/verify to Ollama and reasoning/synthesis steps to Groq
|
|
148
|
+
(LPU). Override the table for your workflow.
|
|
149
|
+
|
|
150
|
+
For cases where the heuristic prompt-content labeler can't tell what kind of
|
|
151
|
+
step a call is, mark it explicitly:
|
|
152
|
+
|
|
153
|
+
```python
|
|
154
|
+
with sploink.step("classify"):
|
|
155
|
+
client.chat.completions.create(...)
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
## What's in the box
|
|
159
|
+
|
|
160
|
+
| Module | What it does |
|
|
161
|
+
|---|---|
|
|
162
|
+
| `sploink.wrap()` | Monkey-patches Anthropic, Groq, OpenAI, Together, Ollama SDK clients |
|
|
163
|
+
| `sploink.trace` | Per-workflow `CallRecord`s, JSONL persistence, summary aggregations |
|
|
164
|
+
| `sploink.classify` | Heuristic step-type labeler from observed call shape (no LLM) |
|
|
165
|
+
| `sploink.router` | Static rule table mapping `step_label → (substrate, model)` |
|
|
166
|
+
| `sploink.route.step` | Context manager for explicit step labels |
|
|
167
|
+
| `sploink.workflow` | Detects RAG / extraction / tool-agent / coding shapes from a trace |
|
|
168
|
+
| `sploink.graph` | DAG data structure for execution graphs |
|
|
169
|
+
| `sploink.architecture` | Visualizes the workflow ↔ substrate bipartite assignment |
|
|
170
|
+
| `sploink.report` | Static HTML report from a JSONL trace |
|
|
171
|
+
| `sploink.canvas` | Force-directed graph visualization of a trace |
|
|
172
|
+
|
|
173
|
+
## Architecture viewer
|
|
174
|
+
|
|
175
|
+
```bash
|
|
176
|
+
python -m sploink.architecture
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
Opens a self-contained HTML showing your workflow IR (left), available substrates
|
|
180
|
+
(right), and the bipartite routing assignment (blue edges in the middle). Switch
|
|
181
|
+
strategies in the dropdown to see how each one redirects the workload.
|
|
182
|
+
|
|
183
|
+
## What works, what doesn't
|
|
184
|
+
|
|
185
|
+
| | Status |
|
|
186
|
+
|---|---|
|
|
187
|
+
| Observability via `sploink.wrap()` | ✅ Works |
|
|
188
|
+
| Per-step classification (heuristic) | ✅ Works |
|
|
189
|
+
| Static routing table | ✅ Works |
|
|
190
|
+
| Concurrent-workflow isolation (asyncio, threading) | ✅ Works |
|
|
191
|
+
| Trace persistence + visualization | ✅ Works |
|
|
192
|
+
| Learned routing from telemetry | ❌ Roadmap |
|
|
193
|
+
| Substrate graph as first-class data | ❌ Roadmap |
|
|
194
|
+
| `Graph.from_trace()` (infer topology from observation) | ❌ Roadmap |
|
|
195
|
+
| Hot-swap routing on customer-supplied DAGs (LangGraph, DSPy) | ❌ Roadmap |
|
|
196
|
+
| Confidential-compute / privacy primitives | ❌ Roadmap |
|
|
197
|
+
|
|
198
|
+
## Bench
|
|
199
|
+
|
|
200
|
+
The bench (in [`bench/`](./bench)) measures whether per-step routing produces real
|
|
201
|
+
cost savings at preserved quality on HotpotQA. To run it locally:
|
|
202
|
+
|
|
203
|
+
```bash
|
|
204
|
+
pip install "sploink[bench]"
|
|
205
|
+
ollama pull llama3.1:8b
|
|
206
|
+
uv run python -m bench.run --n 30 --graphs parallel_dag --strategy edge_routed
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
Results are written to `bench/results/*.csv` and rendered as a comparison table.
|
|
210
|
+
See [`docs/bench.md`](./docs/bench.md) for the methodology and current findings.
|
|
211
|
+
|
|
212
|
+
## Documentation
|
|
213
|
+
|
|
214
|
+
Full docs: **https://s-3-ai.github.io/sploink** (coming soon)
|
|
215
|
+
|
|
216
|
+
In the repo:
|
|
217
|
+
- [`PRD.md`](./PRD.md) — Product requirements / thesis
|
|
218
|
+
- [`docs/`](./docs/) — Concept guides
|
|
219
|
+
- [`examples/`](./examples/) — Runnable demos (mocked + real-API)
|
|
220
|
+
|
|
221
|
+
## Contributing
|
|
222
|
+
|
|
223
|
+
This is pre-MVP solo work right now. Issues and discussion welcome at the
|
|
224
|
+
[GitHub repo](https://github.com/S-3-ai/sploink/issues). Pull requests likewise,
|
|
225
|
+
though the API surface is still evolving.
|
|
226
|
+
|
|
227
|
+
## License
|
|
228
|
+
|
|
229
|
+
[MIT](./LICENSE)
|
sploink-0.1.0/PRD.md
ADDED
|
@@ -0,0 +1,373 @@
|
|
|
1
|
+
# Product Requirements Document: Sploink
|
|
2
|
+
|
|
3
|
+
*Workflow-aware substrate routing and skill generation for AI agents*
|
|
4
|
+
|
|
5
|
+
**Author**: Tim Nguyen
|
|
6
|
+
**Date**: 2026-05-17
|
|
7
|
+
**Status**: Draft v0.3 — pre-MVP (thesis stabilized after Gimlet competitive analysis)
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 1. Summary
|
|
12
|
+
|
|
13
|
+
Sploink is the workflow-and-skill layer for AI agents. It breaks each agent workflow into typed steps, routes each step to the optimal substrate (edge NPU, cloud frontier, cloud specialist, local CPU), directs hardware-level mechanisms (caching, quantization, batching, speculative decoding) per step via the inference layer's APIs, and crystallizes winning patterns into reusable substrate-tuned skills. Developers wrap their existing agent code; Sploink intercepts each step, classifies it by workflow type, and dispatches it to the best available substrate for that type under the developer's cost / latency / quality SLA.
|
|
14
|
+
|
|
15
|
+
**Core thesis (the compression):**
|
|
16
|
+
|
|
17
|
+
> ai agent workflow → typed steps → break steps apart → attribute the right compute per step → edge vs cloud, different hardware types → crystallize winning patterns into reusable skills
|
|
18
|
+
|
|
19
|
+
An agent workflow is a graph of *typed* heterogeneous steps. Step type (classification, embedding, bounded reasoning, frontier reasoning, tool execution, etc.), not just step size, determines the optimal substrate. Today every step runs on the same substrate (usually a closed frontier API), which means most steps overpay by 3–10x. Workflow-aware substrate routing with hardware-level policy directives delivers 30–60% cost reduction on real agent workloads without quality loss, with the savings compounding as the skill layer matures.
|
|
20
|
+
|
|
21
|
+
**Layer positioning:** Sploink sits at the workflow + skill layer, *above* the inference orchestration layer. We consume inference providers (Anthropic, OpenAI, Together, Modal, Groq, Cerebras, eventually Gimlet) as substrates. We are not building an inference engine. The differentiation is that we issue hardware-level directives per workflow step based on step type and observed telemetry — the inference layer below us executes them.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Problem
|
|
26
|
+
|
|
27
|
+
Agent workflows today have 5–20 distinct steps per request: extraction, classification, retrieval, reranking, reasoning, synthesis, tool calls, formatting. Each step has a unique compute fingerprint:
|
|
28
|
+
|
|
29
|
+
- A 50-token classification doesn't need an H100. It needs a 4090 or an NPU.
|
|
30
|
+
- A long-context summarization wants Cerebras or a memory-rich GPU.
|
|
31
|
+
- A latency-critical short-form generation wants Groq's LPU.
|
|
32
|
+
- A frontier reasoning step needs Claude or GPT.
|
|
33
|
+
- A tool call needs a CPU.
|
|
34
|
+
|
|
35
|
+
Despite this, almost all production workflows run every step on the same substrate — usually a closed API or a single inference provider. That's because:
|
|
36
|
+
|
|
37
|
+
1. Routing across providers is operationally painful (different SDKs, different auth, different latency profiles).
|
|
38
|
+
2. Developers have no per-step cost or latency visibility to know which step to optimize.
|
|
39
|
+
3. There's no abstraction that exposes "the substrate" as a first-class routable choice.
|
|
40
|
+
|
|
41
|
+
The opportunity: **make per-step substrate routing a one-line code change.**
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## 3. Vision — four-phase arc
|
|
46
|
+
|
|
47
|
+
Sploink is built as a four-phase stack. Each phase unlocks the next; each phase is a chapter of the same product, not a separate company.
|
|
48
|
+
|
|
49
|
+
- **Phase 1 (now, v1 shipped May 10 2026): Workflow telemetry and cockpit.** Rewind, replay, intervene mid-session. The original wedge. Already live with users.
|
|
50
|
+
- **Phase 2 (next 12 weeks): Hardware-aware workflow + skill generation.** Per-step substrate routing across edge, cloud frontier, and cloud specialists. Hardware-level policy directives (caching, quantization, spec-dec) issued per workflow step based on type. Skill library begins to crystallize from observed routing patterns.
|
|
51
|
+
- **Phase 3 (months 6–18): Skill distillation.** Crystallized skills compress into substrate-tuned specialized SLMs that replace cloud-API calls on the workloads where they outperform on cost, latency, or quality. Telemetry from Phases 1–2 *is* the training signal that no incumbent has.
|
|
52
|
+
- **Phase 4 (year 2+): Agent substrate layer.** Once skill libraries and substrate routing reach scale, Sploink becomes the runtime substrate for the broader agentic economy. Marketplace, composition search, just-in-time agent synthesis.
|
|
53
|
+
|
|
54
|
+
Trigger conditions for advancing phases:
|
|
55
|
+
- Phase 1 → 2: live customer workflows with measurable per-step cost; current state
|
|
56
|
+
- Phase 2 → 3: ≥3 customers on Phase 2 with N workflows running, M skill patterns observed
|
|
57
|
+
- Phase 3 → 4: skill library reaches K distinct substrate-tuned variants used across customers
|
|
58
|
+
|
|
59
|
+
**Do not pursue Phase 3 or 4 as separate companies.** They are the natural output of executing Phase 2 well.
|
|
60
|
+
|
|
61
|
+
## 3.1 The 24-month developer experience
|
|
62
|
+
|
|
63
|
+
A developer wraps their agent code:
|
|
64
|
+
|
|
65
|
+
```python
|
|
66
|
+
from sploink import wrap
|
|
67
|
+
|
|
68
|
+
agent = wrap(my_agent, sla={"cost": "minimize", "latency_p95_ms": 2000})
|
|
69
|
+
result = agent.run(query)
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
Under the hood, Sploink:
|
|
73
|
+
|
|
74
|
+
- Intercepts every LLM call, tool call, and inference step
|
|
75
|
+
- Profiles each step's compute needs (input size, output size, latency requirement, quality bar)
|
|
76
|
+
- Routes each step to the optimal substrate based on the SLA and current substrate cost/availability
|
|
77
|
+
- Falls back to the original frontier API for steps explicitly marked as requiring it
|
|
78
|
+
- Logs every routing decision with cost, latency, and quality attribution to a dashboard
|
|
79
|
+
- Continuously re-evaluates whether a cheaper substrate maintains quality, via background evals
|
|
80
|
+
|
|
81
|
+
The developer never thinks about Groq vs. H100 vs. consumer GPU vs. Claude. They think about cost / latency / quality SLAs and the substrate becomes invisible.
|
|
82
|
+
|
|
83
|
+
---
|
|
84
|
+
|
|
85
|
+
## 4. Why now
|
|
86
|
+
|
|
87
|
+
1. **Substrate diversity is real and growing.** Groq, Cerebras, d-Matrix, AMD MI300, Intel Gaudi 3, Apple Silicon NPU, Microsoft Copilot+ NPU. Each has a distinct cost-perf profile. Five years ago this was "NVIDIA or nothing."
|
|
88
|
+
2. **Open models are good enough for most steps.** Llama 3, Qwen 2.5, Phi-4, DeepSeek-V3 match closed models on extraction, classification, reranking, and summarization. The frontier-only assumption no longer holds.
|
|
89
|
+
3. **Inference cost is the dominant agent-economics concern.** Companies at scale spend $100K–$10M/month on inference. A 3–5x reduction is a real budget line item.
|
|
90
|
+
4. **Gimlet validated the pattern at the inference layer; the workflow + skill layer above is open.** Gimlet Labs ($92M raised through Series A March 2026, ex-Pixie team led by Zain Asgar, partnered with NVIDIA / AMD / Intel / ARM / Cerebras / d-Matrix, customers include a top-3 frontier lab and top-3 hyperscaler) is doing heterogeneous routing at the inference layer for the largest AI labs and hyperscalers. Their existence is validating, not blocking. They operate one layer below Sploink. The Asgar pattern is "lower-layer telemetry → upper-layer decisions": Pixie did it at kernel/application, Gimlet does it at chip/inference, Sploink applies the same pattern at inference/workflow + skill. The developer-facing, workflow-typed, edge-inclusive layer above Gimlet is not occupied.
|
|
91
|
+
5. **Edge substrate has shipped at consumer scale.** Apple Silicon ANE (18–38 TOPS), Qualcomm X Elite (45 TOPS), Intel Lunar Lake NPU (48 TOPS), AMD XDNA2 (50 TOPS). Apple Intelligence and Microsoft Copilot+ commit the trend at the OS level. Edge is the substrate where the full hardware → workflow → skills chain is most realizable; cloud frontier APIs are where the chain collapses to inference-aware observability.
|
|
92
|
+
6. **Specialized SLMs are catching up on bounded reasoning.** Phi-4, Qwen 2.5, DeepSeek-R1 distillations. On bounded reasoning tasks (math, code subtasks, multi-hop search, structured analysis), specialized SLMs now match or beat frontier-via-API at far lower cost. Decomposed-edge reasoning extends this surface further: even tasks that look "frontier-required" can often be broken into bounded chunks that run on edge with a synthesis step.
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## 5. Non-goals (v1)
|
|
97
|
+
|
|
98
|
+
- **Not** building inference hardware orchestration from scratch. Use Modal, Together, Groq, OpenRouter, and (eventually) Gimlet as substrate backends.
|
|
99
|
+
- **Not** competing with Anthropic / OpenAI on frontier reasoning quality.
|
|
100
|
+
- **Not** an agent framework. Plug into LangGraph, CrewAI, raw Python — wherever the agent already lives.
|
|
101
|
+
- **Not** an MLIR compiler stack. Use existing ONNX, TensorRT, MLC-LLM, ROCm toolchains.
|
|
102
|
+
- **Not** a marketplace. The product is the runtime + observability layer.
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
## 6. Users
|
|
107
|
+
|
|
108
|
+
### Primary persona: AI engineer at a Series A–C startup spending real money on inference
|
|
109
|
+
|
|
110
|
+
- Building a production agent (coding assistant, research agent, voice agent, support automation)
|
|
111
|
+
- Current inference spend: $10K–$500K/month
|
|
112
|
+
- Agent has 5–20 LLM/tool calls per request
|
|
113
|
+
- Currently runs everything on OpenAI or Anthropic
|
|
114
|
+
- Pain: bill is growing faster than revenue; no visibility into per-step cost
|
|
115
|
+
- Adoption motion: Python SDK, drop in 10 lines, see savings within a day
|
|
116
|
+
|
|
117
|
+
### Secondary persona: platform/infra lead at a scaled AI company
|
|
118
|
+
|
|
119
|
+
- Owns inference cost budget across multiple product teams
|
|
120
|
+
- Already mixed-model (some open, some closed)
|
|
121
|
+
- Wants per-step observability and substrate flexibility
|
|
122
|
+
- Will adopt as a sidecar/proxy or via SDK integration
|
|
123
|
+
|
|
124
|
+
### Anti-personas (v1)
|
|
125
|
+
|
|
126
|
+
- Pre-PMF startups with small inference bills — savings don't matter to them yet.
|
|
127
|
+
- Enterprise compliance buyers — sales cycle too long.
|
|
128
|
+
- Hobbyists / personal projects — no willingness to pay.
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## 7. Core concepts
|
|
133
|
+
|
|
134
|
+
### Step
|
|
135
|
+
|
|
136
|
+
A single unit of work in an agent workflow: one LLM call, one tool call, one embedding lookup, one rerank operation. Steps are the routing unit.
|
|
137
|
+
|
|
138
|
+
### Workflow type
|
|
139
|
+
|
|
140
|
+
The semantic category of a step, used as the primary input to substrate routing. The current taxonomy:
|
|
141
|
+
|
|
142
|
+
| Type | Optimal substrate | Reasoning |
|
|
143
|
+
|---|---|---|
|
|
144
|
+
| Classification / intent parsing | Edge NPU | Small model, bounded output, latency-sensitive |
|
|
145
|
+
| Embedding | Edge NPU (batched) or cloud GPU at scale | Parallelizable, fixed model |
|
|
146
|
+
| Vector search / retrieval | Local CPU + RAM | Memory-bound, deterministic |
|
|
147
|
+
| Short structured generation | Edge SLM or Groq LPU | Bounded output, token-rate matters |
|
|
148
|
+
| Long-context analysis | Cerebras WSE or H100 cluster | Memory footprint exceeds edge |
|
|
149
|
+
| Bounded reasoning (math, code) | Edge specialized SLM or Groq LPU | Specialized SLMs match frontier |
|
|
150
|
+
| Decomposable bounded reasoning | Edge SLMs with decomposition (CoT, ToT, skeleton) + synthesis | Extend edge surface beyond raw step size |
|
|
151
|
+
| Open-ended reasoning / planning | Cloud frontier | Integrative reasoning, doesn't decompose cleanly |
|
|
152
|
+
| Code generation (substantial) | Cloud frontier or large local on M-series Pro/Max | Quality + context |
|
|
153
|
+
| Tool execution | Local CPU | Deterministic, no inference |
|
|
154
|
+
| Multimodal (vision) | Apple ANE or specialized vision accelerator | Vendor co-design |
|
|
155
|
+
| Quality verification / critique | Edge SLM (light) or cloud frontier (deep) | Bifurcates by depth |
|
|
156
|
+
|
|
157
|
+
### Substrate
|
|
158
|
+
|
|
159
|
+
A compute backend Sploink can dispatch a step to. Each substrate is characterized by cost ($/1K tokens or $/sec), latency profile (P50/P95), available models, and supported step types. Examples:
|
|
160
|
+
|
|
161
|
+
- Modal H100 / L4
|
|
162
|
+
- Together AI (Llama, Qwen, Mixtral on NVIDIA)
|
|
163
|
+
- Groq LPU (Llama, Qwen — latency-optimized)
|
|
164
|
+
- Cerebras (long-context, high-throughput)
|
|
165
|
+
- Anthropic / OpenAI passthrough (frontier reasoning)
|
|
166
|
+
- Apple Silicon / browser WebGPU (edge, on-device, free)
|
|
167
|
+
|
|
168
|
+
### Step fingerprint
|
|
169
|
+
|
|
170
|
+
A profile of a step's compute demands: input size distribution, output size distribution, latency target, quality target, and a step-type label (extraction, classification, reasoning, summarization, etc.). Derived from runtime observation, not declared upfront.
|
|
171
|
+
|
|
172
|
+
### Router
|
|
173
|
+
|
|
174
|
+
The runtime component that maps each step invocation to a substrate, given the step's workflow type, fingerprint, the workflow SLA, and current substrate state (cost, latency, availability). The router does not implement hardware operations; it issues hardware-level directives (precision tier, cache strategy, batching mode, spec-dec policy) to the inference layer's APIs, which execute them on the physical substrate.
|
|
175
|
+
|
|
176
|
+
### Skill
|
|
177
|
+
|
|
178
|
+
A crystallized pattern that combines a workflow type + substrate choice + per-step policy directives + (eventually) a substrate-tuned model variant. Skills emerge from observed routing telemetry: when a routing decision works well across many invocations, it becomes a named, reusable skill. The skill library compounds with usage and is a primary moat artifact.
|
|
179
|
+
|
|
180
|
+
### SLA
|
|
181
|
+
|
|
182
|
+
A per-workflow or per-step constraint set: cost ceiling, latency budget, quality floor. The router minimizes against the SLA.
|
|
183
|
+
|
|
184
|
+
---
|
|
185
|
+
|
|
186
|
+
## 8. v1 scope (MVP — 12 weeks)
|
|
187
|
+
|
|
188
|
+
The smallest thing that demonstrates per-step heterogeneous routing on real workloads.
|
|
189
|
+
|
|
190
|
+
### Must-have
|
|
191
|
+
|
|
192
|
+
1. **Python SDK** that wraps an existing agent (function or LangGraph workflow). Intercepts LLM calls and routes per step. Minimum integration: 5 lines of code.
|
|
193
|
+
2. **4 substrate backends** integrated:
|
|
194
|
+
- Anthropic API (frontier passthrough)
|
|
195
|
+
- OpenAI API (frontier passthrough)
|
|
196
|
+
- Together AI (open models on NVIDIA)
|
|
197
|
+
- Groq (open models on LPU)
|
|
198
|
+
- Stretch: Modal direct, for custom-deployed open models
|
|
199
|
+
3. **Step fingerprinting**: runtime profiling of each step type within a workflow, building a per-step cost / latency / quality table.
|
|
200
|
+
4. **Router v0**: rule-based, profile-driven. No convex optimization yet. Picks the cheapest substrate that meets the SLA based on profiled performance.
|
|
201
|
+
5. **Trace dashboard** showing per-step substrate, cost, latency, and aggregate workflow cost. Hard requirement: customer can see *why* a step was routed where it was.
|
|
202
|
+
6. **Eval harness**: customer-defined eval suite per workflow. Every routing decision is validated against the eval suite asynchronously; quality regressions trigger rollback to the prior substrate.
|
|
203
|
+
7. **Cost dashboard**: aggregate monthly savings vs. baseline (what they would have paid running everything on their current default).
|
|
204
|
+
|
|
205
|
+
### Stretch
|
|
206
|
+
|
|
207
|
+
- Integration with LangGraph as a drop-in execution backend
|
|
208
|
+
- Custom-model deployment (BYO fine-tuned SLM via Modal)
|
|
209
|
+
- Cerebras and d-Matrix backends
|
|
210
|
+
- Workflow-level optimization (joint optimization across all steps, not just per-step)
|
|
211
|
+
- Cold-start mitigation via pre-warmed pools
|
|
212
|
+
|
|
213
|
+
### Explicitly deferred
|
|
214
|
+
|
|
215
|
+
- Edge / on-device routing
|
|
216
|
+
- Marketplace / public skill catalog
|
|
217
|
+
- Multi-tenant billing
|
|
218
|
+
- Enterprise SSO and governance
|
|
219
|
+
- Gimlet as a routing substrate (revisit after their API matures)
|
|
220
|
+
- Convex / formal optimization router (the v1 rule-based router is sufficient)
|
|
221
|
+
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
## 9. Success metrics
|
|
225
|
+
|
|
226
|
+
### v1 launch (12 weeks)
|
|
227
|
+
|
|
228
|
+
- 5 design partners running production workflows on Sploink
|
|
229
|
+
- Demonstrated ≥3x cost reduction on the routable portion of ≥1 workflow per partner, at ≤2% quality regression measured on customer evals
|
|
230
|
+
- 1 published case study with concrete numbers
|
|
231
|
+
- SDK install → first successful wrapped agent run < 30 minutes
|
|
232
|
+
|
|
233
|
+
### 12 months
|
|
234
|
+
|
|
235
|
+
- $100K MRR or 50 paying customers
|
|
236
|
+
- Substrate catalog covers ≥8 backends including ≥2 ASIC vendors
|
|
237
|
+
- Public benchmark dataset of step-type × substrate performance (becomes the data moat)
|
|
238
|
+
|
|
239
|
+
### Anti-metrics
|
|
240
|
+
|
|
241
|
+
- Substrate breadth without usage
|
|
242
|
+
- Dashboard impressions without behavior change
|
|
243
|
+
- Integrations shipped without design-partner traction
|
|
244
|
+
|
|
245
|
+
---
|
|
246
|
+
|
|
247
|
+
## 10. Competitive positioning
|
|
248
|
+
|
|
249
|
+
| Layer | Player | Our relationship |
|
|
250
|
+
|---|---|---|
|
|
251
|
+
| Heterogeneous compute orchestration (infrastructure) | Gimlet Labs, NVIDIA Dynamo, llm-d | Substrate provider — we route to / on top of them |
|
|
252
|
+
| Single-provider inference (NVIDIA-bound) | Together, Modal, Fireworks, Baseten | Substrate backends we route to |
|
|
253
|
+
| AI ASIC clouds | Groq, Cerebras, d-Matrix | Substrate backends |
|
|
254
|
+
| Model API aggregation | OpenRouter, Portkey, Martian | Adjacent — they route between *closed models*; we route between *substrates* |
|
|
255
|
+
| Agent frameworks | LangGraph, CrewAI, LlamaIndex | Integration targets; we run inside their workflows |
|
|
256
|
+
| Observability | LangSmith, Langfuse, Braintrust | We expose hardware-attribution none of them surface |
|
|
257
|
+
|
|
258
|
+
**Our wedge**: workflow-typed, per-step substrate routing with hardware-level policy directives and a crystallizing skill library, exposed via a developer-facing observability cockpit.
|
|
259
|
+
|
|
260
|
+
**The one-line positioning vs Gimlet** (do not pitch as "Gimlet but more"; that anchors to their measuring stick and loses): *"Gimlet routes chips. We route agents. They optimize each inference call; we orchestrate the workflow of many inference, tool, and edge calls under one SLA."*
|
|
261
|
+
|
|
262
|
+
**Why this composition is differentiated** (and where each piece exists individually):
|
|
263
|
+
- Workflow decomposition: LangGraph/CrewAI do this but without type classification or substrate awareness
|
|
264
|
+
- Per-step substrate routing across edge + cloud: nobody does this with workflow type as the primary input
|
|
265
|
+
- Hardware-level policy directives at the workflow layer: rare; most workflow tools don't expose quantization, cache strategy, spec-dec policy per step
|
|
266
|
+
- Skill crystallization from telemetry: novel; OpenPipe-class distillation is customer-directed, not telemetry-driven
|
|
267
|
+
- Decomposed reasoning on edge: research-validated pattern (CoT, ToT, skeleton-of-thought) but no production product applies it as a workflow-layer routing decision
|
|
268
|
+
|
|
269
|
+
The differentiation is the *combination*, not any single piece. Each piece exists somewhere; the integration across all of them is what no competitor has assembled.
|
|
270
|
+
|
|
271
|
+
---
|
|
272
|
+
|
|
273
|
+
## 11. Risks
|
|
274
|
+
|
|
275
|
+
### Technical
|
|
276
|
+
|
|
277
|
+
- **Cold-start latency on diverse substrates**: switching substrates mid-workflow introduces tail latency. Mitigation: keep-alive heuristics, pre-warm common paths, accept cost overhead for latency-critical steps.
|
|
278
|
+
- **Step fingerprinting cold start**: a new workflow has no historical data, so the first routing decisions are uninformed. Mitigation: ship default fingerprints per common step type (extraction, classification, etc.); learn customer-specific fingerprints over time.
|
|
279
|
+
- **Quality regression detection**: hard to know if a cheaper substrate is "good enough" without ground truth. Mitigation: customer-defined evals as a first-class product surface; LLM-as-judge for the long tail.
|
|
280
|
+
|
|
281
|
+
### Market
|
|
282
|
+
|
|
283
|
+
- **Inference prices drop faster than our savings story**: if frontier API prices drop 10x, our 3-5x savings story shrinks. Mitigation: position around aggregate workflow optimization, not raw $/token; emphasize the steps where open models are *already* equivalent and only cost remains.
|
|
284
|
+
- **Gimlet adds a developer-facing SDK**: they could ship the same developer wrapper on top of their orchestrator. Mitigation: speed to developer mindshare; they ship enterprise-first.
|
|
285
|
+
- **Closed-API providers expose hardware choice**: unlikely in 24 months — Anthropic / OpenAI have no incentive — but if it happens, our routing scope on closed APIs grows.
|
|
286
|
+
|
|
287
|
+
### Execution
|
|
288
|
+
|
|
289
|
+
- **Eval infrastructure is hard**: weak evals → weak routing → broken trust. Mitigation: invest in evals from week 1, not as an afterthought.
|
|
290
|
+
- **Cold outreach to design partners is the gating function**: nothing else matters until we have 5 customers willing to run production workflows on Sploink.
|
|
291
|
+
- **18 disciplines to integrate (the breadth tax)**: workflow orchestration, agent systems, hardware architecture, inference systems, ML model architectures, reasoning decomposition, networking, confidential computing, edge runtimes, observability, RL/multi-objective optimization, developer experience, compiler intuition, economics, cryptography, capability theory, benchmarking, GTM. Most of these need fluency, not depth, on the founder side; the team must cover deep implementation for the disciplines the founder doesn't own. Failure mode: paralysis from trying to go deep on all of them. Mitigation: founder goes deep on 4 (workflow + agent systems, hardware architecture at systems level, inference systems mechanics, reasoning decomposition strategies); fluency on the rest; team hires cover implementation depth.
|
|
292
|
+
|
|
293
|
+
### Trust (edge inference's structural objection)
|
|
294
|
+
|
|
295
|
+
The single hardest external objection to the edge thesis: "If you're using compute that isn't yours, how do you trust the result hasn't been tampered with?" (asked by Jason in the May 17 cofounder call). The three-tier answer:
|
|
296
|
+
|
|
297
|
+
1. **For B2B SaaS customers on company-managed devices** (MDM-controlled Macs, Copilot+ PCs in enterprise): the company already trusts those devices. Edge inference inherits that trust. This is the answer for v1 customers.
|
|
298
|
+
2. **For cross-organization edge** (where the device user is not the buying organization): TEE + remote attestation. Apple Secure Enclave, Intel TDX, AMD SEV-SNP. The inference runs in an attested enclave; the attestation report proves the code and weights weren't modified; the workflow layer validates the report before trusting output. Medium-term answer.
|
|
299
|
+
3. **For adversarial users**: probabilistic verification — frontier sampling on a fraction of requests, redundant computation, output consistency checks. Long-term answer.
|
|
300
|
+
|
|
301
|
+
Sploink must be able to articulate all three in any cofounder, investor, or design-partner conversation.
|
|
302
|
+
|
|
303
|
+
---
|
|
304
|
+
|
|
305
|
+
## 12. Open questions
|
|
306
|
+
|
|
307
|
+
1. **Pricing**: per-token markup on routed compute (OpenRouter-style), per-seat SaaS, or a hybrid?
|
|
308
|
+
2. **Open / closed source**: SDK and runtime open-source to drive adoption, hosted dashboard / evals as paid?
|
|
309
|
+
3. **Integration depth**: ship as a Python SDK only, or also as a sidecar proxy customers can put in front of any client?
|
|
310
|
+
4. **First vertical to dominate**: coding agents (developer-native), research / RAG (SLM-friendly), or voice agents (latency-critical, Groq sweet spot)?
|
|
311
|
+
5. **Workflow-level vs. per-step optimization**: v1 is per-step; when do we add joint optimization across steps?
|
|
312
|
+
6. **Gimlet partnership timing**: when (if ever) do we route to Gimlet as a substrate? Their product maturity vs. ours.
|
|
313
|
+
7. **Decomposed-edge reasoning validation**: empirical question — what fraction of real agent reasoning steps are decomposable-bounded (can be chunked, run on edge SLMs, synthesized) vs. structurally requiring frontier? This determines whether edge's addressable surface is 30% or 60%+ of typical agent compute. MVP-able with a benchmark across 3 representative workflows.
|
|
314
|
+
8. **Skill crystallization mechanism**: when does an observed routing pattern become a named skill? Threshold by usage count, by quality stability, by cost-savings magnitude? The crystallization policy is itself a product surface.
|
|
315
|
+
9. **Trust answer per customer segment**: which of the three trust tiers do we ship in v1, v2, v3? The B2B-on-company-managed-devices tier is the v1 answer; TEE attestation is medium-term; probabilistic verification is long-term.
|
|
316
|
+
|
|
317
|
+
---
|
|
318
|
+
|
|
319
|
+
## 13. Milestones
|
|
320
|
+
|
|
321
|
+
| Week | Milestone |
|
|
322
|
+
|---|---|
|
|
323
|
+
| 1 | Thesis validated with 3 prospective customer conversations |
|
|
324
|
+
| 2 | End-to-end demo: one workflow, two substrates, measured cost delta |
|
|
325
|
+
| 4 | SDK alpha: wrap an agent, route between Anthropic + Groq + Together, log traces |
|
|
326
|
+
| 6 | Router v0 with profiled fingerprints; eval harness wired in |
|
|
327
|
+
| 8 | First design partner running production traffic on a single wrapped workflow |
|
|
328
|
+
| 10 | Trace + cost dashboard live; nightly evals running |
|
|
329
|
+
| 12 | 5 design partners, 1 case study, pricing model decided, fundraising deck v1 |
|
|
330
|
+
|
|
331
|
+
---
|
|
332
|
+
|
|
333
|
+
## 14. What we are *not* doing this week
|
|
334
|
+
|
|
335
|
+
- Writing more research memos
|
|
336
|
+
- Reading more papers
|
|
337
|
+
- Drafting a Series A deck before a working demo
|
|
338
|
+
- Building hardware orchestration from scratch
|
|
339
|
+
- Designing a marketplace
|
|
340
|
+
- Building anything customers haven't asked for
|
|
341
|
+
|
|
342
|
+
Everything in v1 serves one question: **can per-step substrate routing deliver real cost savings on real workflows without quality regression?** If yes, this is a company. If no, we learn fast.
|
|
343
|
+
|
|
344
|
+
---
|
|
345
|
+
|
|
346
|
+
## 15. Appendix: terminology
|
|
347
|
+
|
|
348
|
+
- **Step**: one unit of work in an agent workflow (LLM call, tool call, embedding, etc.).
|
|
349
|
+
- **Substrate**: a compute backend Sploink can dispatch to.
|
|
350
|
+
- **Step fingerprint**: profiled compute / latency / quality characteristics of a step.
|
|
351
|
+
- **Router**: runtime component selecting substrate per step.
|
|
352
|
+
- **SLA**: customer-defined cost / latency / quality envelope.
|
|
353
|
+
- **Frontier passthrough**: forwarding a step to a closed API (Claude, GPT) without substrate selection.
|
|
354
|
+
|
|
355
|
+
# Notes
|
|
356
|
+
|
|
357
|
+
**The compression (memorize):**
|
|
358
|
+
> workflow → typed steps → break apart → attribute right compute → edge vs cloud + different hardware → crystallize patterns into skills
|
|
359
|
+
|
|
360
|
+
**One-line mantra (internal):**
|
|
361
|
+
> "Right compute for the right work, and remember what worked."
|
|
362
|
+
|
|
363
|
+
**One-sentence layman pitch:**
|
|
364
|
+
> "Software that makes AI agents cheaper and faster by sending each piece of their work to the right hardware — your laptop's AI chip when possible, the cloud when actually needed."
|
|
365
|
+
|
|
366
|
+
**Three-sentence pitch:**
|
|
367
|
+
> "AI agents do work by chaining a lot of small steps, but today every step runs on the same expensive cloud AI, even when it doesn't need to. Sploink breaks down what the agent is doing, sends each piece to the right place — the user's own laptop AI chip for the small stuff, the cloud for the heavy reasoning — and stitches it back together. You save 30–60% on your AI bill, get faster responses, and keep more of your data on your own machine."
|
|
368
|
+
|
|
369
|
+
**Cofounder-level positioning:**
|
|
370
|
+
Sploink is the workflow + skill layer that uses hardware-layer telemetry to make better routing decisions and to crystallize substrate-tuned skills. We sit one layer above the inference orchestration layer (Gimlet's space). We do not build inference infrastructure; we direct it via APIs. Our moat is the integration across workflow, hardware, skills, and edge — a combination no incumbent has assembled because it requires unusual cross-disciplinary fluency to operate.
|
|
371
|
+
|
|
372
|
+
**Pattern discipline:**
|
|
373
|
+
Phases 1 through 4 are *chapters of the same product*, not separate startups. Resist the urge to spin up adjacent companies when new substrate layers reveal themselves (this has been a recurring failure mode). Write each new framing into the PRD as a future phase with a trigger condition.
|