Designing Genie

Jacques Ramphal·9 min read·Nov 2025

How a delivery team started working with AI, through an agent I built before most of the tools for it existed.

Key learning

No one uses Genie now, but they all use parts of it. Building early meant building things that got replaced, and the parts that survived were the ones about context and judgment, not the ones about automation.

Overview

The first version wasn’t an agent. It was a custom GPT that teams uploaded their project documents into. It was manual, and there was no live link to anything, so the moment a project moved, the GPT was out of date.

We all knew where the real hours went: prepping for meetings, wrangling Jira and Confluence, making sense of unstructured notes, and updating tickets and stakeholder reports. None of it was hard. All of it was the same on every project, and it was what stood between a team and the work a client was paying for.

The question I kept coming back to was smaller than any of that. On a client call, after discovery, I wanted to be able to say: based on your use case, these are the requirements for your project, so what’s missing? Getting something in front of a client early, so the gaps showed up in week one instead of month three.

That question needed live context, not a folder of uploads. So in the spring of 2025 I started building Genie.

The constraint

There was very little to build it with. Agent frameworks were young, nobody I worked with had shipped one, and the tools that now do most of this didn’t exist yet. I built Genie in n8n, a drag-and-drop workflow tool, wired into Slack, a vector database, and the APIs for Jira, Confluence, Drive, Gong and our resourcing system. For years I’d only written code on the side.

The harder constraint was people. Asking “how can I use Genie?” was like asking “how can I use ChatGPT?” It could do too many things for anyone to know where to start, and every wrong answer cost trust I couldn’t easily earn back. I said it plainly at an early office hour: I can’t get your adoption without your confidence and trust, so I need your feedback.

Approach

Context belongs to the project, not the person

Genie lived in Slack because that’s where the teams already were. You added it to a project channel like a teammate and tagged it in a thread. Each channel carried a canvas that worked like an environment file: the project’s Drive folder, its Confluence space, its Jira board. Genie read that canvas every time it was tagged, so the same question in two channels got two different, correct answers.

Direct messages broke that, and I learned it the slow way. A project manager asked for a summary of a specific meeting and got notes from a different project, because they were assigned to several and a DM has no channel to anchor it. The fix was to work out which projects someone was on from their assignments, and to ask when it was ambiguous. The lesson stayed with me longer than the fix: an agent is only as right as the context it thinks it’s in.

Showing its reasoning

An answer on its own wasn’t useful to a designer or a delivery lead. They needed to see whether it was right. When Genie drafted requirements, every one it added that wasn’t in our library said why, and pointed at the line in the statement of work it came from. Later, when it proposed a page, the reasoning came with it, one toggle away.

I wrote the rule down in a demo script for one of those runs: the trust comes from traceability, not from claiming precision we don’t have.

Earning adoption in the open

I ran Genie like a product with an audience of colleagues. There was a support channel, weekly updates, open office hours, and a public roadmap anyone could add to. Feedback went through Genie itself: tell it you’ve found a bug and it walked you through filing the ticket and tagged you on it. My standing advice was to use it until it became a blocker, and then tell me.

The numbers came from Genie too. In one two-week stretch that October it ran 1,773 times successfully and failed 55. The same report told me something less comfortable. Most of the people using it were leads, directors and delivery managers, not the designers and developers doing the daily work. Adoption was coming from the top down, and a tool that only managers use is a reporting tool, whatever I meant it to be.

It made plenty of small mistakes in public. It welcomed new teammates to channels, including other bots, and once posted a welcome when someone was removed. It reminded a new hire in their first week that their timesheet was overdue. Each one cost a little trust, and fixing each one in the open earned some of it back.

Narrowing to the audit

The audit was in the very first demo. I asked Genie to audit a homepage, gave it a URL that didn’t exist, and it found the real one, took the screenshots, and came back with a gap analysis against our component inventory: there’s a hero banner here, we don’t have one, our full-width banner gets close with these changes.

Over the next year that was the part people kept asking for. It grew from one page to deep audits, then to batches of sites at once, then into a pipeline: audit, compare competitors, synthesise findings, score opportunities, map the site, prototype. When a request came in for fifty sites, the kind of scope that used to be declined, Genie compiled ten full audits in two hours.

Rebuilding when the tool hit its ceiling

n8n let me control every step, and I hit the edge of what it could reach constantly. The question that settled it came out of a conversation about a case study for Genie: could we share it with clients? Could we sell it? Not on a drag-and-drop canvas tied to our own accounts.

So I rebuilt it on Claude, as commands written in plain markdown with scripts behind them. Things I’d been stuck on for months opened up. I gave up watching each step happen and got back reach. (I’ve told that trade at more length in Taste is triage.)

Letting what the client already knew outrank the score

The rebuild made Genie more capable, and the first time it was confidently wrong in front of a client, I agreed with it. It audited a deals site, and its top recommendation was to give the deal cards more room. The client had already tested that and it lost: cards on screen dropped from three to one and a half, and on a site where people scroll through cheap offers, fewer deals on screen is fewer sales. Every number in the audit was right, and the recommendation was backwards. I caught it out loud, in the room. (The longer version is here.)

The fix wasn’t a better score. It was feeding Genie what the client already knew, and ranking that evidence above its own reasoning. On the same engagement, its simulation first recommended adding express checkout. Given the stakeholder data, it found that express checkout had already been tested and had hurt conversion, and it took its own recommendation back.

Outcome

Most of what Genie did in 2025 is now done by other things. Orium’s company-wide delivery platform builds questionnaires, scopes and estimates, writes health reports and executive digests, and files meeting transcripts against the right account, from one connected record per project. Those were Genie’s workflows, and they’re better served by a platform built for them.

The parts that were never about automation survived. The audit and its pipeline now run as commands in the design kit I build, and designers use them on client work. Genie’s whole idea, that an agent is only as good as the context you give it, became how we talk about delivery. It fed directly into a spec-to-code accelerator I didn’t start: a storefront is written down once as a specification and the code is generated from it. I now work on the design layer of that specification.

It changed my own work just as much. Genie brought me back to development after years of doing it on the side, and I came out the other end designing how agents behave as much as how screens look. The company later recognised the work with its highest AI award level, the one for work that changed how it operates.

What I learned

My strongest numbers were anecdotal, mid-flight or unmeasured, and I wrote that down when I was asked to make the case for this work. I’d rather say it here too. What I can stand behind is the shape of it: what got built first, what got replaced, and what was still useful afterwards.

Building before the tools existed meant building a lot that didn’t last. I don’t count that as waste. The people who use the platform now arrived with a sense of what an agent with project context could do, because they had argued with one in Slack for a year.

How building Genie changed how I work: Building Genie changed me →