When personal automation becomes organizational infrastructure
Carlos Robledo is a Lead Technical Sourcer at Hims & Hers. When he got tired of spending hours every Friday building hiring reports for stakeholders, he built Rex, a 19-workflow system that now serves recruiters across the talent organization.
There was a specific moment that triggered Rex. While working with his Chief Product Officer, Carlos was responsible for producing two major updates across several open requisitions. The work meant moving between the applicant tracking system, Slack, and other tools to assemble a clear picture of where candidates stood.
As his workload grew, so did the problem. Carlos was managing more than 15 requisitions, while some of his team maters carried 20 to 25. Candidate updates, interview changes, stale applications, and offer activity could easily fall through the cracks.
Carlos had always thought in systems. He had ideas about how recruiting operations could work better, but he had never had the technical ability to build those systems himself.
AI and Zapier changed that.
The Friday report problem
Carlos began with a simple question: could he automate the pipeline updates he was already preparing manually?
He started by checking whether Ashby exposed the information he needed. Then he used Zapier to connect the data to the tools where the recruiting team already worked.
The first version of Rex focused on reporting. It pulled recruiting information into Airtable and Slack, giving Carlos a more reliable way to monitor active requisitions and share updates with hiring teams. From there, the system expanded around real friction points: stale-candidate monitoring, interview creation and cancellation updates, offer-acceptance notifications, pipeline reports, referral and inbound applicant workflows, and alerts for candidates sitting outside service-level expectations.
Each new feature came from a problem teammates actually felt. Carlos would build a version, ask teammates to test it, collect feedback, fix bugs, and return with the next iteration.
“I started with my team, understanding their needs and my own thoughts,” he says. “Then I realized those pain points translated into endpoints and information Ashby exposed.”
From scheduled reports to on-demand answers
Rex initially delivered reports at a scheduled time. That helped, but Carlos realized a fixed delivery schedule was still based on his assumption about when people needed the information.
So he built an on-demand Slack interface.
Recruiters could use /rex to request pipeline information when they needed it, rather than waiting for the next scheduled update. The system returned a structured response directly in Slack, formatted for quick reading and action.
That shift changed the role Rex played in the team. It was no longer just a reporting workflow. It became an internal recruiting tool.
Carlos also created a quick guide and short video showing people how to enroll a role and use the system. The goal was not simply to tell people Rex existed. It was to make the first interaction easy.
Adoption came from solving problems people already felt
Carlos started with his immediate team. He asked what would help, built against those needs, and returned with working versions for people to test. That process surfaced bugs and clarified which features mattered.
Once Rex had matured, his manager introduced it to recruiting leadership, including the VP of Recruiting and SVP of HR and People. Leadership then brought Carlos in to demonstrate the system to roughly 60-70 people across the broader People function.
He showed them how to enroll a position, what a weekly report looked like, and how Rex could provide information to recruiters and stakeholders without requiring another manual data pull. The message was simple: if someone could identify a useful problem, they could begin exploring whether they could build the solution.
The system now supports recruiters across the organization, with up to 50 recruiter-hours recovered each week according to Carlos’s estimate. The more important change is that recruiting teams have a shared view of work that previously lived across individual tools, inboxes, and memory.
Why Rex beat the AI bot
Carlos also experimented with an internal bot connected directly to Ashby through MCP. The bot offered better access control and could retrieve recruiting information, but it could not reproduce the structured Slack experience he had built with Rex. Its output was less predictable and harder to scan.
That comparison clarified something for Carlos. More direct AI access did not automatically create a better employee experience.
Rex worked because each part of the system had a defined role. Zapier handled orchestration. Ashby provided recruiting data. Airtable stored and organized information. Slack provided the interface. AI helped with the parts that benefited from interpretation, but the overall workflow remained structured and repeatable.
“Rex is actually something very tangible and very important to the team,” Carlos says. “It just works perfectly as it is.”
Rex is deliberately deterministic where correctness matters. The machinery — pulling data from Ashby, organizing it in Airtable, applying the rules for what "stale" means or when feedback is overdue, assembling the report, and delivering it to Slack on schedule — runs the same way every single time. That repeatability is what makes recruiters trust it.
AI shows up in two places. First, and most importantly, it's how the system gets built and improved: it's what let a systems-oriented recruiter act on ideas he previously couldn't build himself — reading the data, shaping the workflows, and turning a teammate's request into a working feature quickly. Second, at the edges that benefit from interpretation — understanding a plain-language /rex request and turning raw stage data into a briefing a person can actually read, rather than a table dump.
The balance is the point: deterministic where the answer has to be right, AI where design, interpretation, and communication make the difference.
The largest lever is per-role status: rebuilding the standing of every candidate, one requisition at a time.
Reading and compiling a single role's pipeline by hand takes about 20 minutes. Across the full book of roughly 143 open requisitions, doing that just once a week comes to about 2,860 minutes — nearly 50 recruiter-hours every week spent simply assembling status, before anyone has scanned for stalls, chased feedback, or answered a stakeholder's question.
That's the work that on-demand reporting removes. With /rex reporting available across every enrolled requisition — effectively the entire open-role book — no recruiter has to hand-build any of it. Add the smaller daily activities on top, and it's easy to see how the recovered time can reach up to 50 recruiter-hours a week.
What teammates asked for, and which requests became features
Almost every part of Rex traces back to a real friction point that a recruiter raised. Carlos would build a version, ask teammates to test it, collect feedback, fix what broke, and come back with the next iteration. His first testers weren't technical specialists — they were recruiters trying to manage heavier and heavier workloads, which made their feedback the truest signal for what mattered.
The requests that became features:
"Keep me current on interviews as they change" → interview creation and cancellation updates.
"Tell me who's been sitting too long" → stale-candidate monitoring, delivered as a weekly nudge.
"Don't make me hunt for missing interview feedback" → the feedback-chase flow, which flags overdue feedback and gives the recruiter a one-click way to remind the interviewer.
"Tell the channel the moment an offer is accepted" → offer-acceptance notifications.
"Let me ask when I need it, not wait for the schedule" → the on-demand /rex interface.
"Warn me when a candidate is outside of SLA" → SLA alerts for candidates sitting outside expectations.
Plus the referral and inbound-applicant workflows that grew around the same needs.
The pattern is simple and it's the heart of the story: a recruiter hits a snag, and it becomes a Rex behavior — because the system is composable pieces, not a locked product.
The builder multiplier
Rex began as Carlos’s answer to a reporting problem. It became a system that helped other recruiters manage their own work.
A personal automation saves its builder time. An internal product changes how a team operates.
Carlos starts with a specific problem, tests whether the underlying systems can support a solution, builds a small version, and improves it with real users. The result is not a theoretical AI capability. It is a recruiting workflow people can use when a candidate changes status, a role needs attention, or a hiring manager needs an answer.
Carlos didn’t set out to build an AI product for his recruiting organization. He set out to stop rebuilding the same pipeline report every week.
Then he made the solution useful enough for others to adopt.
