Harnessloop
Frameworks
The open-source stacks we use and the proprietary frameworks that support our production AI delivery process.
Frameworks
Harnessloop builds on open-source stacks and two internal frameworks that support our delivery process. This page explains the tools we use and the internal systems we built when a stock integration was not enough.
LangChain
We're Official LangChain Ambassadors.
We organized Poland's first official LangChain meetup, bringing the local AI engineering community together around production patterns rather than demo-day tricks.
Day to day, we build with the LangChain stack across client work. LangGraph is our default for orchestration wherever an agent needs branching logic, retries, or a human-in-the-loop step. LangSmith runs underneath most of what we ship, for evaluation and observability once a system is in front of real traffic. Ambassador status isn't a badge we mention once and move on from. It reflects the stack we reach for on client projects by default, not the exception.
LlamaIndex
Harnessloop brings LlamaIndex Ambassador expertise to retrieval-augmented generation and knowledge-base work. We use it to ingest a client's scattered documentation, tickets, and internal wikis into a system an agent can query with source context. Where LangChain and LangGraph carry orchestration, LlamaIndex supports retrieval for knowledge systems.
Pydantic AI
We use Pydantic AI for the parts of a system where a wrong answer isn't an annoyance, it's a broken downstream process: structured outputs, tool-calling with strict schemas, and agents that hand off to other software rather than to a person reading a chat window.
Pydantic's type-safety guarantees, extended into the agent layer, cut down a category of failure that's otherwise hard to catch before it reaches production: the model returning something that parses as valid JSON but doesn't match what the rest of the system expects. For client integrations where an agent's output triggers a database write, a CRM update, or an API call with real consequences, this is the layer that keeps the system honest.
Our own frameworks
Our internal frameworks make the delivery process explicit. We build tooling on top of the open-source stack, then use AI in a closed loop to research, plan, implement, review, and improve that tooling. This gives client systems the benefit of a delivery process with concrete checks, not just access to the same model providers.
SignalMap
Before we write a line of production code, we need an accurate picture of what a client's systems actually do, not what the org chart says they do. Our mapping framework is the internal tool that gets us there: it traces a client's existing workflows, data flows, and system boundaries, and turns that into an architecture-ready blueprint an engineering team can build against.
This is what makes the Mapping/Blueprint stage of our process fast instead of a multi-week discovery slog. Clients who already know what's broken get a precise map of where automation slots in. Clients who don't get a clear picture of where the highest-leverage opportunities are, backed by how their systems actually behave, not a slide deck of assumptions.
ForgeLoop
Going from a validated proof of concept to something running in production, with failover, observability, and real monitoring, is where many AI projects stall. Our delivery framework is the internal pipeline that gets a defined production increment from a scoped requirement to deployment in one to two weeks when the scope and access are ready.
The framework runs in stages:
- Scoping. Client requirements, transcripts, and existing documentation get turned into a structured build plan, ready for engineering rather than another round of clarifying meetings.
- Architecture & build. Engineers design and build against the blueprint from the mapping framework, with the system decomposed into components an agentic workflow can build and test in parallel.
- Quality & hardening. We define pass and blocker criteria, then review the components and the system behavior against them. The required checks depend on the risk and scope of the build.
- Deploy & observe. We plan monitoring, operational ownership, and the failure handling the production increment needs before it goes live.
- Iterate. We stay embedded post-launch, watching how the system performs against real traffic and refining it as usage patterns show up.
This structure supports fixed pricing for a defined engagement and a one-to-two-week production increment where the scope and access are ready.