I built Tieline so my agents can understand the product, not just the code
With codebase wikis, most are written more from an engineering lens, explaining how the code works without explaining why it should work that way.
I wanted to connect business intent directly to its implementation using language that nontechnical people already use. I've been experimenting with creating my own software factory, and wanted a way for myself and all my agents to 'speak the same language', with a clear 'contract' on how specific features should work. I built Tieline so all my agents can work from the same product contract, even if they do not have access to the codebase.
Tieline generates user stories and acceptance criteria, then links them to the code and tests that implement them. This lets an agent answer questions like:
- What is this feature supposed to do?
- Which code and tests implement it?
- Which behaviours might this change impact?
Tieline also builds a static topology graph of the codebase. When code changes, it can trace the possible impact through that graph and connect it back to the relevant acceptance criteria.
This creates a product-level blast radius. It does not claim that something will break. It gives the agent and reviewer a shortlist of behaviours that may need another look.
Tieline generates the initial product contract for you to review. After that, it checks pull requests and proposes updates when the implementation changes.
On top of tracking current product state, Tieline lets you track feature requests, bugs, and ideas as Observations. The accepted production contract lives in the repository and can be synced to Postgres, while Observations stay in Postgres, accessible by all your agents via MCP.
Agents without codebase access can query this information through MCP, allowing coding, product, research, and support agents to work from the same accepted product state while also seeing where the product may be going next.
While experimenting, the unexpected benefit has been identifying quick wins. While working one feature, I'll ask my agent to check the backlog. Semantic search finds related items that fit naturally into the current work and fits them in the PR.
Still experimental, but my goal is to make the repository the reviewed source of truth for product behaviour, then make that contract available to every agent, not only the engineering ones.
Open source project: https://github.com/knoxgraeme/tieline
Would love any feedback or to hear how others are thinking about these problems!