Barberi(Barber Intelligence)

Barberi is a governed AI that runs your barbershop, cares for every customer, and waits for your approval before anything that matters happens. It does that in Multilanguages (English and Arabic.)

Comment

Inspiration

A barbershop makes hundreds of small decisions a day: stock running low, a customer cancelling at the last minute, a message in Arabic that nobody on shift can answer. Almost none of them need the owner. A few absolutely do, like anything that spends money or speaks to a customer on the shop's behalf. Software has never known which is which.

Most AI agents are built to do more. We wanted to build one that knows when not to act. Barberi is a governed agentic intelligence: an agent that runs the shop and cares for every customer, inside rules it cannot talk its way around.

What it does

Barberi does three things:

  • Runs the shop. The owner asks for prices in plain words. Barberi drafts a request for each supplier, reads the replies, recommends the best offer, and places the order only after the owner decides. Employees ask for leave in plain words too.
  • Cares for every customer. Customers get a personal scalp and skin analysis from a QR scan, and can book, cancel or move services, ask FAQs and shop timings in English or Arabic. Every conversation follows the shop's own rules from its knowledge base.
  • Waits for your decisions. A scheduled rule notices low stock or an empty chair on its own. Barberi asks suppliers for prices, or finds regulars who are due back, and then pauses for the owner's approval.

How we built it

Governance is the architecture, not a feature added on top.

  1. Every message is a workflow. Each incoming message or scheduled event starts an AWS Step Functions state machine, so every turn has a defined start, steps and end.
  2. Reasoning with limits. The agent runs on Amazon Bedrock AgentCore with only the tools it is allowed to use. A thinker model (Claude Sonnet 4.6) drafts, and a separate verifier model (Claude Haiku 4.5) checks the draft, for example that it leaks no supplier names or prices. Bedrock Guardrails mask personal data.
  3. An enforced policy gate. Before any action (send, book, order) a Cedar policy is evaluated in enforce mode.

A rule can only say yes. It can never grant more than it was given.

  1. One door out. All outgoing messages leave through a single channel-send step (email, WhatsApp, SMS) with an at-most-once guarantee, so nothing is sent twice.
  2. Proactive, and watched. EventBridge schedules find low stock and empty chairs. Each schedule has a watchdog alarm, because for a background job silence is the failure.

Challenges we ran into

  • Autonomy versus control. Deciding what the agent may do alone was the hardest design question. Asking suppliers for a price is safe to automate. Placing the order is not.
  • Making the agent trustworthy, not just capable. Prompts alone were not enough, so the rules moved into an enforced policy gate and a separate verifier.
  • Silent failures. A scheduled job that quietly stops is worse than one that errors, so we added watchdog alarms.
  • Two languages, one set of rules. An answer in Arabic has to follow the same shop policies as one in English.

What we learned

  • Governance works best as architecture: separate the model that thinks from the one that checks, and from the policy that permits.
  • Owners trust an agent that shows its work and waits for approval more than one that is merely fast.
  • Designing the "needs you" moments carefully matters as much as the automation.

What's next

More shop workflows under the same gate, support for more languages, and letting owners edit their own policies in plain words. ACE opportunity ID: O29250776 | AWS Partner ID: 2619138 (BEYOND VERB FOR DESIGN & CONSULTANCY)

Built With

Share this project:

Updates

Submission history