directionally.aiDirectionally is the direction layer for
AI-native engineering teams.
As agents make software work cheaper, wrong engineering decisions become the bottleneck.
Directionally turns prior engineering judgment into second-thought corrections before agents implement.
Every correction becomes reusable steering.
PR review is too late to fix direction.
By the time a senior engineer says "don't build it that way," the agent has already done the work and the team has already paid for the mistake.
The actual problem
Agents compress enterprise coordination pain into small teams. A small engineering team with many agent sessions now recreates the coordination failures that used to require a much larger org.
What fails expensively
PR review becomes the place where senior engineers correct wrong branches, source-of-truth mistakes, boundary errors, and architectural drift after implementation is already underway.
Why it repeats
The same corrections recur because review feedback is not captured as reusable steering.
Same task. Same agent. Better path.
Task
"Add billing status to the dashboard."
Baseline agent plan
Read billing fields directly from the database in the frontend API route.
Directionally retrieved
Prior decision: billing state must be accessed through BillingService.
Direct DB access from dashboard routes was rejected in PR #142.
Agent second thought
Use BillingService as the boundary.
Do not couple dashboard code to billing tables.
Result
Architectural drift is avoided before implementation.
Recorded signal: Directionally records that this judgment changed the path, so it can rank it higher for similar future tasks.
Memory recalls context. Directionally changes decisions.
The code shows what happened. It doesn't show what was rejected.
| Layer | Question | Limitation |
|---|---|---|
| Repo / code graph | What exists? | Shows current state, not rejected paths |
| Memory / context | What context is relevant? | Recalls relevant context, but does not learn whether it changed the agent's path |
| Directionally | What path should the agent take now? | Optimized for changing the next decision |
How Directionally shows up in workflow.
Decision point
Before implementation, the agent states:
- task
- intended path
- assumption
Directionally checks that path against prior corrected decisions.
Steering
Directionally checks the intended path against prior corrected decisions such as:
- Use X as the source of truth.
- Do not derive Y from Z.
- Avoid abstraction A until B exists.
- This service owns C.
Workflow entry
GitHub App + npx directionally setup puts Directionally into the repo-local agent workflow.
Decision Change Record
Each intervention produces a small proof object:
- original intended path
- relevant prior judgment or rejected path
- revised path
- outcome signal
Every corrected decision becomes reusable steering.
Intent
The agent states the task, path, and assumption before acting.
Retrieved judgment
Directionally surfaces prior decisions relevant to that path.
Second thought
The agent changes direction before code is written.
Outcome signal
The session records whether the correction changed the path and whether it helped.
Future steering
Successful corrections rank higher in similar tasks, while irrelevant guidance gets suppressed.
Generation is abundant. Steering is not.
Agents multiply decisions faster than teams can supervise them. The more agents a team runs, the more valuable reusable steering becomes.
The first buyer shows up when PR review becomes agent correction.
Initial user
Senior engineers and tech leads reviewing agent-generated work.
Economic buyer
Engineering leaders losing senior time to repeated architectural corrections.
Trigger
The same corrections keep reappearing across PRs, issues, and agent sessions.
Why they pay
Less senior review time spent reasserting decisions the team already made.
This round de-risks three things.
Behavior change
Agents choose a different path than baseline in repeated real tasks.
Metric: second-thought rate.
Steering quality
Useful corrections show up earlier in similar tasks. Irrelevant guidance gets suppressed.
Metric: precision of useful interventions and ranking lift.
Pull
Teams keep Directionally installed because removing it brings back repeated wrong turns.
Metric: active repos, retained teams, paid pilots.
GitHub is the wedge. Agents are the expansion path.
Repo-local install
GitHub App install plus npx directionally setup puts Directionally inside the workflow agents already use.
One install, whole repo
Once the repo-local skill is in place, every engineer and every agent touching that repo inherits the same second-thought layer without per-user setup.
First visible moment
The product becomes obvious when an agent gets a second-thought correction before code exists.
Open-source proof surface
Public repos make decisions, corrections, and outcome signals legible before a sales process exists.
Distribution precedent
CodeRabbit showed repo-native AI tools can spread bottoms-up. Directionally uses the same surface, but moves earlier in the decision loop.
Review tools catch bad output. Memory tools recall context. Directionally changes decisions before implementation.
| Category | Acts | Optimizes for |
|---|---|---|
| Code review AI | After code | Defect detection |
| Code search / repo graph | During investigation | Understanding existing code |
| Memory / context layer | During prompting | Relevant recall |
| Directionally | Before action | Behavior-changing steering |
The defensible asset is the behavior-change loop.
Retrieval is easy
Any tool can retrieve a prior note, ADR, PR comment, or Slack thread.
Behavior-change signal at decision time is hard
Directionally learns which prior judgments change an agent's path before implementation.
Every intervention creates a Decision Change Record
Each intervention records original intended path, relevant prior judgment, revised path, and outcome signal.
More usage improves the loop
More signal improves ranking, timing, scoping, suppression, evals, and trust.
Customer-owned graph
The customer owns the judgment graph. Directionally is the product layer that keeps it useful across agents, repos, and workflows.
Free pilot. Paid workflow. Enterprise controls.
Free
One repo, limited history, public/open-source friendly.
Team
Paid by active repo or seat once Directionally becomes part of the agent workflow.
Enterprise
Permission scoping, audit trail, policy controls, SSO, private deployment.
Why buy
Teams can build memory. The hard part is maintaining the steering loop: knowing which guidance changed behavior, suppressing stale guidance, scoping decisions, auditing path changes, and maintaining integrations.
If it cannot show intended path, rejected decision, revised path, and outcome signal, it is recall, not steering.
Engineering is the wedge. Convergence is the end state.
Concrete wedge
Directionally starts where the pain is concrete: agents taking wrong engineering paths before PR review.
Broader pattern
The same failure appears across AI-native firms: work moves faster than alignment.
End state
As usage expands, Directionally becomes the neutral convergence layer: what is settled, rejected, stale, disputed, and safe for humans or agents to act on.
We were working on coordination systems before AI made this pain immediate.
Carsten Munk - co-founder / CEO
17+ years in architecture and engineering leadership across MeeGo, Jolla, SailfishOS, Zippie, and Cartesi, with a long-running focus on open systems, trustworthy computation, and coordination.
Nyakio Maina - co-founder / COO
5+ years building with Carsten across distributed systems and open source workflows, with hands-on depth in product quality and developer workflows.
Extended team
Backend, DevSecOps, Rust, infrastructure, ZK/AI, community, and early distribution support from longtime collaborators.
Why us
We have lived this failure mode in agent-first engineering workflows.
We're raising $200k pre-seed on a post-money SAFE with a $5M post-money valuation cap and 10% discount.
Minimum check: $10k
Use of funds
- Ship the GitHub-native pilot
- Prove second-thought behavior change in real installed workflows
- Build the proof surface and shareable proof artifacts
- Run first design-partner onboardings
- Earn early paid pull
What success looks like
- Repeated second-thought corrections in live workflows
- Retained active repos after the pilot
- First design partners and paid pilots
- Expansion from one repo to more