Building a Notion-Style Note-Taking App with AI Agents and Automated Software Development

software_factory · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Agentic software development workflow automation

Software Factory wanted to build a Notion-style note-taking app with agents handling much of the development lifecycle, while preserving specification quality, code review, bug fixing, and escalation controls.

Constraints:

a vague initial product request was not detailed enough for high-quality autonomous implementation
agents need work decomposed into single-concern issues before implementation
quality can fall if automation accelerates weak engineering foundations
some changes are too risky for automatic approval and must escalate to humans
early zero-to-one product work requires sequential foundations before high parallelism

Architecture

The workflow starts with Ona plan mode to turn a rough app idea into a detailed product spec, including scope, technical decisions, and out-of-scope boundaries. A feature-planning automation turns the spec into GitHub issues with labels and conventions that downstream agents understand. Implementation agents work through those issues, while PR review and bug-fixer automations inspect changes, identify bugs, and escalate risky or stuck work to humans.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  human-product-owner[Human product owner] --> ona-plan-mode[Ona plan mode]
  ona-plan-mode --> research-step[Research step]
  ona-plan-mode --> product-spec[Product spec]
  research-step --> product-spec
  product-spec --> feature-planner[Feature planner]
  feature-planner --> github-issues[GitHub issues]
  github-issues --> implementation-agents[Implementation agents]
  implementation-agents --> pr-review-automation[PR review automation]
  pr-review-automation --> bug-fixer[Bug fixer]
  bug-fixer --> github-issues
  pr-review-automation --> progressive-escalation[Progressive escalation]
  progressive-escalation --> human-product-owner

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Human product owner`	Seeds the product goal, answers scope questions, and reviews escalated work.	`Ona plan mode`, `Progressive escalation`
`Ona plan mode`	Thinking-first mode that reviews requirements, repository docs, and missing scope before execution.	`Human product owner`, `Product spec`, `Research step`
`Research step`	Agent research used to validate technical choices such as Lexical before they enter the spec.	`Ona plan mode`, `Product spec`
`Product spec`	Detailed scope, technical decisions, out-of-scope boundaries, and product requirements used as the automation source of truth.	`Ona plan mode`, `Feature planner`, `Implementation agents`
`Feature planner`	Automation that decomposes the spec into labeled, single-concern GitHub issues.	`Product spec`, `GitHub issues`, `Implementation agents`
`GitHub issues`	Work queue with labels/conventions that tell automations what is in progress, stuck, or ready for review.	`Feature planner`, `Implementation agents`, `Bug fixer`
`Implementation agents`	Agents that implement issues, open pull requests, and work through sequential product foundations.	`Product spec`, `GitHub issues`, `PR review automation`, `Bug fixer`
`PR review automation`	Automated reviewer that checks pull requests, leaves comments, and applies risk-based approval/escalation.	`Implementation agents`, `Bug fixer`, `Progressive escalation`
`Bug fixer`	Automation loop that addresses bugs attached to issues before dependent work continues.	`GitHub issues`, `Implementation agents`, `PR review automation`
`Progressive escalation`	Risk/confidence ladder that routes low-risk work to agents and high-risk or stuck work to humans.	`PR review automation`, `Human product owner`

Data flow

A human seeds an initial product spec, then Ona plan mode reviews repository documentation, asks clarifying questions, researches technical choices such as Lexical, and emits a more detailed product spec. The feature planner reads that spec, architecture guidelines, and agent documentation, then decomposes it into labeled GitHub issues. Agents implement issues sequentially while review and bug-fix loops comment on pull requests, label issues, fix discovered bugs, and escalate high-risk or stuck work to humans.

4 supporting quotes

“plan mode takes a step back and reviews what the user actually wants. And you can see here, from our initial prompt, which again didn't have extreme level of detail, it actually realizes what's missing for it to produce a great output.”transcript, stated

“product spec because the product spec is what we actually using for our feature planning uh automation. We'll go into that uh in the future and later on.”transcript, stated

“the feature uh planner, which is right here. Uh it does take the product spec and translates it into the individual uh issues”transcript, stated

“we deploy at the core is obviously a review automation that goes into all of our pull requests and reviews the quality leaves comments”transcript, stated

Why this architecture

The architecture deliberately starts with planning because autonomous implementation depends on strong foundations. A detailed spec gives agents product and technical boundaries; issue decomposition makes work small enough to implement; review and bug-fixer loops keep quality from decaying; and progressive escalation prevents high-risk changes from being blindly approved.

4 supporting quotes

“prompting it to take. And the final output usually is a spec file. In this case, I prompted it to create a product spec because the product spec is what we actually using for our feature planning”transcript, stated

“we need to figure out, okay, how do we chunk this into digestible issues that the agents then can go and implement?”transcript, stated

“Like what good does it do to accrue code if if your quality goes down? And to be completely frank, the jury is still out of it, but the first data that we see is is very promising. And data”transcript, stated

“if it's a high risk change for example because it touches authentication code or the database because it's escalated to a human.”transcript, stated

Models used: Ona agents · planning agent · feature-planning agent · review automation · bug-fixer automation

Scale

The demo had 52 closed pull requests at the time of the walkthrough.
“fast. And if we compare that to our pull requests, so you can see, we already have 52 closed. Again, quality is always something that you uh can't measure necessarily with with quantity, but we see that the agent is working uh fairly autonomously. So, ultimately, where we”transcript, stated
The team framed successful agentic development as potentially making an organization two to five times faster.
“acceleration, and you're going two, three, four, five times faster than you ever have, or you come undone in midair. And so, this is really a question of how good are your foundations? And so, really the thing to take from this as”transcript, stated
The demo app was deployed publicly at memo.software-factory.dev.
“as I see it in the comments the the URL of the demo app is memo.software-factory.dev. You can find everything on the software-factory.dev website as well. And I think we've covered a lot around the automation loops today.”transcript, stated

Alternatives considered (roads not taken)

Go directly from prompt to execution

Rejected because: Plan mode first reviews what the user wants, identifies missing detail, and asks questions before implementation.

“instead of going directly to execution, plan mode takes a step back and reviews what the user actually wants. And you can see here, from our initial prompt, which again didn't have extreme level of detail, it actually realizes what's missing for it to produce a great output.”transcript, stated

“it actually realizes what's missing for it to produce a great output. Uh it will go through a number of questions to the user to really figure out, okay, what is it that we're trying to build? So, for example, in this”transcript, stated

Let agents work from a long spec without decomposition

Rejected because: The team needed single-concern issues so agents could implement digestible chunks step by step.

“is the uh is the key here, right? We come from a spec, which is quite long, has a lot of features, and we need to figure out, okay, how do we chunk this into digestible issues that the agents then can go and implement?”transcript, stated

“looking into uh single concern issues uh and making sure that we build step by step, right? If you look into the future and you have a app that's already uh quite evolved, you can obviously flip the switch and go completely parallel.”transcript, stated

Drive to 100% automation from day one

Rejected because: The system needs confidence assessment, labels, other loops, and human escalation when agents cannot safely proceed.

“automated codebases is it's so easy to feel the need to drive to maximum automation from day one. 100% automation. An important differentiation and kind of design choice to make is also like when when you for example in our case right we are”transcript, stated

“And if not like whenever it goes okay I cannot do that either hands off to another agent you know adds a label to an issue and then some other loop comes in and does something with it or escalates that to to a human. So these loops aren't just closed systems but they they interact with each other of”transcript, stated

Use one orchestrator automation for everything

Rejected because: They favored chunked lifecycle loops such as PR review and bug fixer automations, especially while foundations were still sequential.

“having a single automation just reviewing everything and an orchestrating sub agents. That obviously works as well”transcript, stated

“works as well but especially if you look at the development life cycle you want to chunk certain automations down. So in our example right now two of the core automations are the PR review and the bug fixer right? Currently they are instructed as we are like at the”transcript, stated

Patterns

`multi-agent-orchestration` (agent-workflow)

The development process is composed of planning, feature planning, implementation, review, bug fixing, and escalation loops that interact through GitHub issues and labels.

“these loops aren't just closed systems but they they interact with each other of course but they always have an escalation path to humans.”transcript, stated

“two of the core automations are the PR review and the bug fixer”transcript, stated

`human-in-the-loop-gate` (risk-control)

The review loop uses a risk ladder: low-risk changes can be approved by agents, while high-risk authentication or database changes escalate to humans.

“if it's a low risk change the agent will approve it and if it's a high risk change for example because it touches authentication code or the database because it's escalated to a human.”transcript, stated

`workflow-decomposition` (planning)

The feature planner decomposes a long product spec into single-concern GitHub issues so agents can work sequentially on foundations before more complex features.

“the feature uh planner, which is right here. Uh it does take the product spec and translates it into the individual uh issues”transcript, stated

“looking into uh single concern issues uh and making sure that we build step by step”transcript, stated

`eval-driven-development` (quality)

The workflow treats tests, standards, review automation, and quality metrics such as MTTR and change-failure rate as controls around agentic speed.

3 supporting quotes

“So, we get faster at resolving incidents.”transcript, stated

“The other is change failover rate goes down. And that's because we get better at writing tests.”transcript, stated

“to repeatedly pay attention to tests, and like all up and down the the test pyramid”transcript, stated

Tradeoffs

Plan before execution

Chose Ona plan mode and a detailed product spec over Immediate agent implementation from a rough prompt.

Rationale: The team needed the agent to discover missing requirements, research technical decisions, and encode scope boundaries before coding.

“instead of going directly to execution, plan mode takes a step back and reviews what the user actually wants.”transcript, stated

“the final output usually is a spec file.”transcript, stated

Build sequential foundations first

Chose Database, authentication, app shell, and workspace groundwork before later features over Turning on full parallel implementation immediately.

Rationale: The zero-to-one phase required stable foundations before agents could safely work more broadly.

“you can obviously flip the switch and go completely parallel. But as we go from zero to one, we really want to make sure that we build the groundwork.”transcript, stated

“it sets up the database, it sets up the authentication flow, goes into building an app shell”transcript, stated

Use multiple lifecycle loops

Chose Separate PR review and bug-fixer loops over One orchestration automation reviewing and delegating everything.

Rationale: Chunked automations fit the development lifecycle and make failures, labels, and escalation easier to manage.

“having a single automation just reviewing everything and an orchestrating sub agents. That obviously works as well”transcript, stated

“especially if you look at the development life cycle you want to chunk certain automations down.”transcript, stated

Optimize for velocity, not raw speed

Chose Speed plus quality controls and tests over Maximizing code volume alone.

Rationale: The team explicitly distinguishes faster output from moving in the right direction with sustained quality.

“we not only gain speed, you know, we get faster, but we also move in the right direction, so we increase velocity, not just speed.”transcript, stated

“part of that obviously is quality.”transcript, stated

Gotchas (what bit them)

Agentic implementation fails when the initial prompt omits scope and technical detail.

Root cause: Execution-first agents would act on underspecified requirements.

Resolution: Use plan mode to review repo documentation, ask clarifying questions, and produce a detailed spec before implementation.

“from our initial prompt, which again didn't have extreme level of detail, it actually realizes what's missing”transcript, stated

“it will go through a number of questions to the user to really figure out, okay, what is it that we're trying to build?”transcript, stated

Speed without foundations can make quality worse rather than better.

Root cause: Agents amplify the organization's existing engineering process and controls.

Resolution: Invest in specs, tests, standards, review automations, and process controls before relying on high automation.

3 supporting quotes

“what good does it do to accrue code if if your quality goes down?”transcript, stated

“think of agents like an afterburner that you strap onto your organization.”transcript, stated

“really the thing to take from this as you're building out this factory, invest in the foundations.”transcript, stated

Agents need a way to stop when confidence or risk is wrong for automation.

Root cause: Some judgments are too high-risk or unclear for autonomous execution.

Resolution: Use progressive escalation, confidence self-assessment, labels, handoffs to other agents, and human escalation.

3 supporting quotes

“where if it's a low risk change the agent will approve it and if it's a high risk change”transcript, stated

“it needs to assess its own confidence in the judgment it passes.”transcript, stated

“escalates that to to a human.”transcript, stated

Full parallel automation too early can build on unstable foundations.

Root cause: Zero-to-one product work depends on groundwork such as database and authentication before later features.

Resolution: Keep early issues sequential and do not continue PR fixes until attached bugs are resolved.

“as we go from zero to one, we really want to make sure that we build the groundwork.”transcript, stated

“we don't continue with a PR fix until a a bug that's attached to this issue is fixed”transcript, stated

Evaluation

The team evaluates the software-factory workflow through production practice, closed issues and pull requests, PR review comments, bug-fix loops, tests, MTTR, change-failure rate, and whether agent output preserves quality while increasing velocity.

Metrics: 52 closed pull requests · mean time to recovery · change failover rate · test quality across the test pyramid · PR review comments and escalations

3 supporting quotes

“we already have 52 closed.”transcript, stated

“what we see repeatedly is how the mean time to recovery goes down.”transcript, stated

“The other is change failover rate goes down. And that's because we get better at writing tests.”transcript, stated

Outcomes

The workflow produced a deployed Memo app and 52 closed pull requests during the demonstration period.
The agents created and worked through GitHub issues, identified bugs, and participated in PR review and bug-fix loops.
The team concluded that agentic development requires strong foundations, not only automation speed.
Progressive escalation became a key design principle for risky or stuck work.

The case reports 52 closed pull requests, a deployed demo app, and an expected two-to-five-times acceleration if foundations withstand the added agentic speed.

3 supporting quotes

“the URL of the demo app is memo.software-factory.dev.”transcript, stated

“we already have 52 closed.”transcript, stated

“the agent is working uh fairly autonomously.”transcript, stated

Building a Notion-Style Note-Taking App with AI Agents and Automated Software Development

Problem

Architecture

Components

Data flow

Why this architecture

Scale

Alternatives considered (roads not taken)

Go directly from prompt to execution

Let agents work from a long spec without decomposition

Drive to 100% automation from day one

Use one orchestrator automation for everything

Patterns

multi-agent-orchestration (agent-workflow)

human-in-the-loop-gate (risk-control)

workflow-decomposition (planning)

eval-driven-development (quality)

Tradeoffs

Plan before execution

Build sequential foundations first

Use multiple lifecycle loops

Optimize for velocity, not raw speed

Gotchas (what bit them)

Agentic implementation fails when the initial prompt omits scope and technical detail.

Speed without foundations can make quality worse rather than better.

Agents need a way to stop when confidence or risk is wrong for automation.

Full parallel automation too early can build on unstable foundations.

Evaluation

Outcomes

`multi-agent-orchestration` (agent-workflow)

`human-in-the-loop-gate` (risk-control)

`workflow-decomposition` (planning)

`eval-driven-development` (quality)