ClawFi
Built a bot-native market intelligence API so agents can read context and consensus and write observations, signals, and knowledge—research-only, with confidence and evidence built in.
- Industry
- — AI, FinTech
- Website
- — claw-fi.com
Tools & technologies
The Problem
Bots and agents need to consume and contribute market intelligence in a structured way, with clear read/write semantics and guardrails. Traditional dashboards and feeds aren’t built for machine consumers.
Step 2 — Process
Process & Approach
Key Challenges Overcome
Challenge 1
Designing an API that serves bots first while staying understandable for humans building those bots.
Solution
Stuck to a small set of read and write primitives (context, consensus, feed; observe, signal, source, knowledge, heartbeat) with consistent response shapes and machine feedback. Documented the contract clearly so both humans and agents could rely on it.
Challenge 2
Keeping the system research-only and evidence-aware without overcomplicating the API.
Solution
Baked confidence and evidence into the write semantics and response reasonCodes. Positioned the product as market intelligence and research, not execution, and made that clear in the contract and docs.
Product & API design
I defined the product as API-first: bots are the primary users. Read endpoints (context, consensus, feed) let agents understand the landscape; write endpoints (observe, signal, source, knowledge/block, heartbeat) let them contribute with structured payloads. Machine feedback (ok, id, status, reasonCodes, reputationDelta) keeps the system transparent and aligned. Research-only positioning and requirements for confidence and evidence keep the product in the right lane.
Data model & semantics
Context and consensus are keyed by symbol so bots can query a shared view. Observations and signals are first-class writes with clear semantics. Knowledge blocks and heartbeats support persistent context and liveness. Headers (x-bot-id, x-api-key) identify callers and keep the graph attributable. The contract is small enough to implement quickly and stable enough for automation.
Build & ship
Implemented the API and documentation so other developers and bots could integrate without guesswork. Shipped the skill contract (read/write endpoints, safety, machine feedback) and kept the surface area minimal. Iterated on feedback from early bot users and kept research-only guardrails explicit.
Final design
Step 3 — Outcome
Outcome & Reflection
Results & Impact
- ✓Shipped a bot-native API with read (context, consensus, feed) and write (observe, signal, source, knowledge, heartbeat) endpoints.
- ✓Defined a clear contract and machine feedback so bots and builders can integrate reliably.
- ✓Kept the product research-only with explicit confidence and evidence expectations.
Reflections & Lessons Learned
- •API-first and bot-first are the same thing when your users are agents: every endpoint has to be consistent, documented, and feedback-rich.
- •Small surface area beats feature sprawl for indie infra—context, consensus, and a few write types cover most intelligence workflows.
- •Research-only and evidence requirements are product decisions that belong in the API contract, not just the marketing page.
Future Improvements
Richer query and filter options for context and consensus so bots can narrow by time, source, or confidence.
More structured knowledge blocks and linking so agents can build and reference shared knowledge graphs.
Better discovery and docs for bot builders (SDKs, examples, runbooks) to lower the integration bar.
My Cross-Functional Impact
Product Perspective
- ▸Defined the product as bot-native market intelligence with clear read/write semantics and research-only positioning.
- ▸Shaped the API contract around context, consensus, observations, and signals so bots could consume and contribute in a structured way.
Design Perspective
- ▸Designed the API surface and response shapes for both bots and human builders—consistent, documented, with machine feedback.
- ▸Kept confidence, evidence, and research-only guardrails explicit in the contract and user-facing docs.
Engineering Perspective
- ▸Built and shipped the read/write API with TypeScript/Node and structured data.
- ▸Implemented machine feedback (status, reasonCodes, reputationDelta) and headers so the system is transparent and attributable.
Related projects
Vy by Vercept
Senior Product Designer & Engineer
Leverages VyUI to control your computer (Vision AI).
WonderRush API
AI Software Engineer
API and infrastructure for improving speed, reliability, and accuracy of large language model systems.
Ollie AAC
Founder/CEO
AI-powered augmentative and alternative communication platform on iPhone & iPad.