The Parker Avery Group

The Parker Avery Group is a retail consulting and AI firm in Atlanta, Georgia. It was founded in 2007, works across the United States and Eastern Europe, and has run an India practice in Pune since 2023. Its main product is a forecasting platform, published today as Unified Demand Intelligence, which has its own entry here, and earlier as Enterprise Intelligence. It tracks how each part of a retail business sells, and it predicts the next sales with AI. It started as an in-house product and grew into something the firm sells to its clients.

I joined in 2022 as a Senior Developer, and I still work there. My part is the ground the platform stands on, the modules built on top of it, and the AI assistant published as Ask Udi.

In 2022 the full-scale invasion of Ukraine cut the money flows at Mobilauto, and everyone's contracts got paused. I left for a nearby country in March and came back in the summer. My full-time chapter at Mobilauto was coming to an end, so I started looking for the next one.

So I went back through the connections I'd built between 2020 and 2022. Recruiters had been writing to me anyway, saying they liked my CV, and I spent about three weeks going from one interview to the next. Most of them went well, and I think that's because I had experience behind me and wasn't desperate for any one seat. One company got pretty close to a contract, but once we got into the details, I found problems with them and walked away.

No outside recruiter found me for The Parker Avery Group. The firm doesn't hire the way most companies do. It's a closed process, and somebody inside has to recommend you. I got recommended and spoke with the main team lead, with another hiring process running in parallel. The reason I ended up at The Parker Avery Group is simple: they sent a contract the next day. It would have been the same day, but it was a Friday, and the accountant wasn't in.

My first months went into foundations: the delivery pipeline, the Kubernetes cluster the platform runs on, and the GraphQL query gateway the application talks to. Some of the internal services talk GraphQL, and I designed and built the federated gateway that joins them into one. In 2022 that was the shape of the platform, separate services behind a single front door. The application sends one question to one address, the gateway hands its pieces to the services that each own their slice of the data, and it joins what comes back into one result. Federation couldn't carry subscriptions back then, so I built subscription support into it myself: a real-time channel that pushes a change to every browser window that has the screen open, so a screen that has to move with its data gets the update without asking for it over and over.

It was also the first job where I used AWS for pretty much everything. Before, I mostly worked with Google Cloud, Oracle Cloud, DigitalOcean when I needed a virtual machine really fast, and Azure services. I knew AWS already, but it's a big platform and more or less the standard for cloud work, and I spent real time adjusting my head to it.

After the foundations, I moved on to new modules, new services and new pages, and I worked across the shared backend: identity, fine-grained authorization, users, roles and groups.

Then came the AI assistant, now published as Ask Udi. I'm its main author, with other engineers working on it too. The idea was a way of speaking with your data. A user asks the retail data a question in everyday language and gets a table, a chart or a report back, with no query to write.

A plain text-to-SQL agent takes the question, goes to the database and hands the rows back. That's fine until the answer runs to thousands of rows, and the AI still has to show it to you. So the question gets routed first: small talk, a database query, or a "big data analysis run". For a query, the model writes it and runs it by calling a tool. The query gets validated before anything runs, and the model's part stops there. The server executes the query and keeps the full result under an "artifact". The model gets only a sample of about 100 rows, the total row count, and a placeholder for the rest, and it writes its answer around that placeholder. The browser reads the placeholder, fetches the full dataset by its id and draws the whole table or chart.

This keeps the model cheap and quick. It never sees the full dataset, the raw rows stay on the server, and the user still gets every row. Everyday questions go to a cheaper model, and a stronger one is kept for the new ones.

If Mobilauto was my school for being a developer, The Parker Avery Group was my college and university for being an enterprise dev. The One word apart, and a lot of meaning in that word. Being a good developer, or a good SRE or DevOps engineer, doesn't cover the big "Bone" behind every change, the one you have to understand and analyze each time you touch it. The codebase has a real test suite and a pipeline that runs on every change. Tracing sits on the AI, so we can go back and see exactly what it did with a given question. Even so, a well-tested change can still miss something, so you keep a plan B behind plan A, and plan A isn't really your plan A either.

The team is senior, and by senior I mean years of experience in a field. We don't have real disputes about what to do, and every change goes through review without it ever feeling like friction. The team is really professional. Obviously it's a job, but here I really feel like part of a big job family.

The Parker Avery Group, and the product names Unified Demand Intelligence and Ask Udi, belong to The Parker Avery Group.