Architecture
Use Open Source for Plumbing, Keep Kam Intelligence Custom
9 min read
Kam AI
Product and research
5th Grade Summary
Kam should not install every AI platform.
Open-source tools can help with tracing, labeling, evals, drift, workflows, and cost tracking.
But Kam's real value is its own sports intelligence layer.
Use tools for plumbing. Keep the product brain custom.
There is no single GitHub repo that gives Kam the full system it needs.
That is not because open source is weak. It is because Kam's system is domain-specific. The valuable part is the glue between sports workloads, source rules, hot reads, labels, fixtures, review flows, release gates, and agentic work.
What open source can help with
Tool categories around Kam
- Category
- Observability
- Example tools
- Langfuse, Phoenix
- Kam use
- Inspect LLM/tool traces and debug answer paths
- Category
- Standards
- Example tools
- OpenInference, OpenTelemetry
- Kam use
- Align span names and attributes for future portability
- Category
- Labeling
- Example tools
- Label Studio, Argilla
- Kam use
- Backup or inspiration for human review workflows
- Category
- Evals
- Example tools
- OpenAI Evals, promptfoo, DeepEval
- Kam use
- Patterns for registries, JSONL cases, CI checks, and judge metrics
- Category
- Drift
- Example tools
- Evidently
- Kam use
- Metric reports and drift checks if Python pipelines help
- Category
- Workflows
- Example tools
- Temporal
- Kam use
- Later durable execution if KamAgentic scale demands it
- Category
- Data pipelines
- Example tools
- Dagster
- Kam use
- Later lineage and scheduled data asset materialization
- Category
- Gateway
- Example tools
- LiteLLM
- Kam use
- Later provider routing or spend tracking if Bedrock-only becomes limiting
Takeaway: The stack should be selected by bottleneck, not by trend.
What should stay Kam-native
Kam should keep the following custom:
- workload IDs
- route contracts
- sports entities
- source separation rules
- hot-read contracts
- failure taxonomy
- label schema
- fixture promotion
- release gates
- workload scorecards
- KamOps review flows
Comparison
Generic AI answer vs Kam-style answer
Question: Should Kam replace its own framework with a generic AI platform?
Weak generic answer
A generic platform can show traces, run prompt evals, collect feedback, and track latency or cost, but it does not know Kam's sports workloads.
Kam-style answer
The Kam framework knows route contracts, sportsbook and prediction-market separation, denominator requirements, labels, fixtures, and release gates.
Generic tools are useful when they serve the domain model. They should not replace it.
Adoption order
Do not adopt a giant platform all at once.
The better order is:
- Strengthen Kam-native registry, labels, fixtures, and scorecards.
- Align trace attributes with OpenTelemetry/OpenInference where practical.
- Add Phoenix or Langfuse if trace inspection becomes painful.
- Use Label Studio or Argilla only if KamOps labeling UI is delayed.
- Use promptfoo or OpenAI Evals patterns for prompt and regression organization.
- Add Evidently for drift reports if exported trace tables need richer analysis.
- Consider Temporal, Dagster, or LiteLLM only when the operational pain is clear.
Use now, soon, later
Use now
OpenTelemetry/OpenInference concepts, private eval registry patterns, and promptfoo-style CI discipline.
Use soon
Phoenix or Langfuse for trace inspection, Evidently for drift reports, external labeling only if KamOps is delayed.
Use later
Temporal for durable worker scale, Dagster for data assets, LiteLLM for provider and spend routing.
Takeaway: Selective adoption keeps Kam from turning quality work into tool sprawl.
Why not copy a blueprint
Reference blueprints are useful because they show the shape of the loop:
production traffic -> dedupe -> label -> dataset -> evaluate -> improve
Kam should borrow that shape. It should not copy a fraud-detection stack, a generic agent OS, or a prompt-testing product as-is.
Sports intelligence has its own product obligations:
- team/player/date entities
- ticket state
- watchlists
- ATS denominators
- source separation
- market freshness
- saved reads
- human review
- release gates
The architecture has to respect those obligations.
The lesson
Open-source tools can accelerate Kam, but they are not the moat.
The moat is the domain-specific operating loop: Kam traces, Kam labels, Kam fixtures, Kam release gates, and Kam agentic workflows. Tools can visualize, run, or support parts of that loop. They should not own the loop.
The next action is to document the integration boundary for each tool before adopting it: what it owns, what Kam owns, and what evidence moves between them.
Read next
Related field notes
kam-frameworkai-operating-system
Kam AI Is Becoming an Operating System
Why Kam is moving from AI chat into a production loop of traces, labels, graders, fixtures, release gates, and agentic work.
9 min read
intelligence-registryworkload-id
The Kam Intelligence Registry
How a workload-centered registry connects traces, labels, fixtures, judge evidence, agentic runs, work items, and release gates.
8 min read
context-checksmoat
Catch Moves. Don’t Chase.
Why Kam is not just chat: it watches your spots, checks what moved, and gives you the read before you chase a bad number.
16 min read