Inside the Intake Process: How Archy Assistant Turns a Raw Idea into a Working Backlog Inside Jira
One Friday afternoon, one blank Jira epic, and a walk through what actually changes when Archy Assistant sits underneath the intake process — told as it happened, not as a feature list.
Product5 min read

Friday, 4:52 PM
The cursor blinks in an empty Jira epic titled Add SSO for enterprise tier. Maya has typed the title and nothing else, and now she's doing the math she does every Friday afternoon: how many sub-tasks, how much acceptance-criteria writing, how many architecture assumptions stand between her and the weekend. She knows this feature. She's known it was coming for three weeks. That doesn't make the blank description field any less blank.
She could write it the way she always has. A paragraph of context, five stories guessed from memory, a story point pulled from nowhere in particular, and a silent hope that whichever engineer picks this up in two weeks reads her mind about the parts she didn't have time to write down. She's done this a hundred times. She also remembers, with the specific clarity of a bad afternoon, the last time a feature like this shipped — the session-handling bug that surfaced in week three because nobody had asked what happens to a user who's already logged in when the auth method changes underneath them. Nobody had asked because nobody had written it down. It wasn't in the ticket. Nothing was, really, except the title.
The two sentences she'd have typed anyway
This time she opens the Archy panel instead of a blank description box, and types the same two sentences she'd have written regardless: enterprise customers need SSO, rollout has to be gradual, existing sessions can't just break. That's it. That's the whole idea, in the same rough shape it existed in her head five minutes ago. She hits enter on the Archy Assistant command and watches the epic that was empty a moment ago start to fill in, sub-task by sub-task, the way a photograph used to develop in a darkroom — not all at once, but not slowly enough to make her nervous, either.
Five stories appear under the epic: provisioning, session handling, admin configuration, audit logging, fallback authentication. Nothing exotic — she'd have arrived at most of these herself, eventually, probably around story three, after she'd already forgotten to write acceptance criteria for story one. What's different is that they're all here at once, each with criteria attached, each sized. The guessing part of her Friday afternoon is just... done.
Under the epic, a second note appears — shorter, almost offhand. It points at the existing auth service and flags, plainly, that session storage will need to change if the migration is going to be gradual instead of a hard cutover. Maya sits back. That's the exact bug from three months ago, arriving before the sprint even starts instead of during week three of it. Not because anything mystical happened — because the system had actually looked at what auth-related work had gone sideways before, on this codebase, and said so.
Then a link appears, unprompted: a "blocked by" relationship to a ticket already sitting in the identity team's backlog — their SCIM work, which this feature will need and which nobody on Maya's team had thought to check for. She hadn't asked about it. She hadn't known to ask. It surfaced anyway, because the platform underneath Archy Assistant had already connected the dots between what she typed and what the rest of the org was already doing.
What she does next matters more than what appeared
Here's the part that's easy to skip past: Maya doesn't accept any of it as-is. She deletes the fallback-authentication story — not needed, this customer segment doesn't require it, and no amount of pattern-matching against other companies' auth rollouts could have told the system that. She rewrites two of the acceptance criteria because they're technically correct and organizationally tone-deaf, missing a compliance detail specific to this particular enterprise contract. She reads the session-storage flag, decides it's real, and leaves it. She reads the SCIM dependency, checks it against what she actually knows about the identity team's roadmap, and leaves that too.
None of that editing is friction. It's the job — the part of intake that was always hers and was never going to belong to anything else. The difference is what she was editing. A week ago it would have been a blank page. Today it's a draft that already knows what happened last time, already knows what the identity team is working on, and got both of those things right without her having to remember to ask.
Monday
Sprint planning doesn't run the way it usually does. Nobody discovers the identity team dependency mid-conversation, because it's been sitting linked to the epic since Friday, already accounted for in the timeline. Nobody argues about scope, because the stories already have acceptance criteria specific enough to size against. The architecture conversation — normally a separate meeting, normally scheduled for whenever someone remembers to schedule it — already happened, in effect, three days earlier, when the cost of changing course was still nothing at all.
This is the part that doesn't show up in any single ticket: the compounding effect of every epic starting from the same floor instead of whatever floor a given PM had energy for on a given Friday. Backlog, architecture, risk, dependency — not four boxes to check, but four questions that get asked automatically now, at the one moment in a feature's life when asking them is still cheap.
If you want to see this running against your own backlog instead of Maya's, you can book a walkthrough at meet.archy-ai.com. And if you're more interested in how we think about architecture-aware AI tooling than in any one Friday afternoon, archy-ai.com is where that thinking lives.


