Activity
Mon
Wed
Fri
Sun
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
What is this?
Less
More

Owned by Hani

Welcome to Agentic World, a hub for AI architects collaborating to build and scale next-gen multi-agent workflows.By Dr.Hani Akrim

41 contributions to AI Automation Society
Okayyyy 👀 GPT-6 Astra got my attention.
Not because it’s the newest shiny thing 😆 Because stronger computer use + browsing + real task execution is exactly where I need agents going. Today I was deep in a WST evidence report and would’ve missed a live WeyDe partnership email if my watch system hadn’t caught it. That’s the goal for me: I do the work only I can do. My agents watch the edges. And the more capable they get, the more governance matters. Astra is officially on my test list. 🔥
1 like • Sep 7
Wasilis nailed it with the risk class distinction. And there's a harder version of this problem in regulated enterprise: Astra's architecture makes it ineligible not just for acting, but even for watching. If your agent is doing live browsing through OpenAI's infrastructure, data has already left your boundary. For a bank under SAMA or a hospital under PDPL, the watch event itself is a compliance event — not just the action it triggers. So the evaluation question for enterprise isn't "is it governed?" It's "is it sovereign?" Astra is a cloud-resident agent by design. That disqualifies it from any regulated context where the observation layer has to be air-gapped, not just the execution layer. Sharon's framing — useful, governed, and reliable — is exactly right. The missing fourth word for regulated markets is auditable: every observation, every decision, every action logged on infrastructure you control, not OpenAI's.
🏆 Weekly Wins Recap | August 29 – September 4
From first law-firm clients and $6K + MRR pipelines to outage-proof AI systems and explosive audience growth, this week inside AIS+ showed that real work keeps paying off. 🚀 Standout Wins of the Week inside AIS+ 👉 @Ryan Cunningham turned 2 free case studies into a potential $6K build + $1K MRR pipeline, showing how proving value first can open the door to paid work. 👉 @Glenn Meleder turned a warm reach-out into his first client project, building email triage automation and a local AI Brain for a law firm. 👉 @Harshit Kumar automated a 300-keyword weekly SEO report for a client, eliminating around 6 hours of manual work every single week. 👉 @Tanya Maslach grew from 72 to 20K+ Instagram followers in just 2 weeks, with one post reaching 2.5M views and 350K interactions. 👉 @Mike AI Consultant built his AIOS with enough redundancy that his client work kept running even when major AI providers went down. ⸻ 🎥 Super Win Spotlight | @Bruce Harrison Bruce joined AIS+ with a non-technical background and quickly realized something important: Knowing how to build AI systems wasn’t enough. He also needed to learn how to explain the value, earn trust, and communicate with business owners in language they actually understand. That shift helped him land interviews with Fortune 500 companies and step confidently into higher-level discovery conversations. He even says he gained more practical value from AIS+ than from a certification program that cost him nearly $5,000. His biggest takeaway? Don’t just learn how to build. Learn how to communicate, sell the outcome, and earn the trust to implement it. 🎥 Watch Bruce’s story 👇 ✨ Building the system is only half the game. Inside AI Automation Society Plus, members are learning how to turn those skills into real conversations, clients, and opportunities.
🏆 Weekly Wins Recap | August 29 – September 4
3 likes • Sep 7
Win this week: shipped the first working version of a sovereign AI intake pipeline for a KSA financial services client — fully on-prem, zero external API calls, compliant with SAMA data residency requirements. The pipeline ingests Arabic-language documents, classifies them against internal risk categories, and routes to the right analyst team — all running on local infra with audit logs baked in. Took 6 weeks from whiteboard to production. The constraint that made it hard (no cloud APIs) was the same constraint that made it trustworthy to the client. That's the regulated market paradox: the harder it is to build, the more the client trusts it. Grateful for communities like this one — seeing what's possible when AI and automation get executed properly accelerates my own thinking.
1 like • Sep 7
@Abdul Aziz Memon From what I've seen in regulated enterprise markets: communicating ROI is the hardest and the most important. Technical implementation is table stakes — if you can't build it, you're not in the room. Client acquisition matters but in GCC enterprise, most deals come from relationships, not funnels. The real leverage is being able to sit with a VP of Risk at a bank and explain in their language why your pipeline reduces audit exposure, not just "saves analyst hours." SAMA doesn't care that you processed 10,000 documents. They care that every inference is logged, traceable, and explainable on demand. The operators who've pulled ahead aren't the strongest builders — they're the ones who learned to frame automation in the client's risk vocabulary. Technical skill got them the first meeting. ROI framing won the deal.
Building AI for markets where "just use the cloud" isn't an option
Most AI automation content assumes you can plug into OpenAI, store data in US servers, and ship fast. That's not the reality for a huge chunk of the world. I build enterprise AI systems in Saudi Arabia — banking, government, healthcare. The constraints are completely different: → Data sovereignty: nothing leaves the country. Period. → Arabic-first: not a translation layer on top of English models — native Arabic reasoning. → GRC baked in from day one: SAMA, NCA, PDPL compliance aren't optional add-ons. → Air-gapped deployments: some clients literally can't touch the public internet. What I've found: the same agent orchestration principles you're learning here apply perfectly — but the stack underneath looks nothing like n8n + OpenAI + Zapier. Curious if anyone else here is building for regulated industries (healthcare, finance, legal) where the default "cloud AI" playbook breaks down. What constraints are you working around? The automation logic is universal. The infrastructure assumptions are not.
2 likes • Sep 7
@Constantin C. Great question. It depends on the use case and client risk profile. For document classification and extraction (our first production pipeline): NVIDIA A100s on-prem inside the client's data center — dedicated inference nodes, not shared cloud. Models are Llama-3-based fine-tuned on Arabic financial documents. For latency-sensitive workflows (real-time compliance screening): we're testing H100 clusters with quantized models (4-bit GGUF via llama.cpp) to hit sub-500ms on document pages. The hardware procurement is actually one of the harder parts of the deal — we work with certified local vendors who can supply, rack, and support inside KSA. SAMA won't sign off on a deployment where the GPU lives in a region outside the kingdom. The model runs on the iron. The iron lives in the building. That's the only way it clears the audit.
Welcome! Introduce yourself + share a career goal you have 🎉
Let's get to know each other! Comment below sharing where you are in the world, a career goal you have, and something you like to do for fun. 😊
5 likes • Sep 7
Hey everyone! I'm Dr. Hani Akrim, coming to you from Riyadh, Saudi Arabia 🇸🇦 I'm the founder of NABDs.AI — building a sovereign Enterprise AI OS for KSA and the GCC regulated markets (banking, government, healthcare — where data can't leave the country and compliance isn't optional). Also running DBH, an AI & GRC consultancy. My background: AI/ML Engineer focused on healthcare AI, RAG systems, and workflow automation. Built HAClaw (an AI legal assistant) and currently scaling enterprise-grade agentic systems for the Arab world. Career goal: Make NABDs.AI the infrastructure layer powering enterprise AI across regulated markets — purpose-built for sovereignty, the way AWS became the default cloud. For fun: I overthink AI architecture at 2am and convince myself it's productive 😅 Stoked to be here — especially to go deeper on agent orchestration. That's where the real enterprise leverage lives. 🚀
1 like • Sep 7
@Gal Miller First target: the regulated financial services intake pipeline. Banks here receive thousands of Arabic-language documents — loan applications, KYC packets, audit reports. Today analysts manually triage them, which is slow and inconsistent. The automation: ingest documents on-prem, classify each page against a risk taxonomy, extract key fields, and route to the right analyst queue — all with a full audit log of what the model saw and what it decided. The sovereign constraint is what makes it interesting. Nothing touches a cloud API. The classification model runs air-gapped, the vector store lives on-prem, and every inference is logged with a timestamp and model version for SAMA examination. Not just "AI-assisted" — defensibly auditable. That's the first production deployment. After that: the same pipeline for healthcare prior-authorization packets under PDPL.
How to structure while building web apps?
For those building full-stack web apps with Claude Code, what workflow has worked best for you? How do you structure the development process between: • UI/UX & product planning • Frontend • Backend & database • APIs/integrations Do you design the complete UI/UX first, then build the backend and frontend around it? Or do you build backend → APIs → frontend? Or is it better to develop everything together feature-by-feature (UI + frontend + backend)? I’m especially curious about the best approach for a larger/production-level project where you want to avoid messy architecture and major rework later. Would love to hear how experienced builders structure this from Day 1.
0 likes • Sep 7
For large-scale apps with Claude Code, the order that's worked best for me: data model first, then API contracts, then feature-by-feature. Here's why: Starting with UI leads Claude to make assumptions about the data shape that become expensive to undo later. Starting with backend alone means you build infrastructure for requirements you haven't validated. Feature-by-feature keeps you shipping but can create inconsistent patterns across the app without an upfront model. The sequence I use: 1. Define the data model in plain language first (entities, relationships, constraints, what can change vs. what's immutable). Get this into a CONTEXT.md or similar before writing any code. 2. 2. Spec the API contracts — what each endpoint takes, returns, and what errors it can produce. Even if Claude is building both ends. 3. 3. Then build feature-by-feature with UI + backend together, referencing the model at each step. The reason this works with Claude Code specifically: Claude is better at staying consistent when it has the data model in front of it than when it's inferring structure from the UI as it goes. For apps with access control (multi-role, permissions, sensitive data): add a step zero — define who can see and do what before you write any schema. Retrofitting access layers onto a working app is one of the most painful refactors there is.
1-10 of 41
Hani Akrim
4
66 points to level up
@hani-akrim-3055
Hi, I'm Dr.Hani Akrim AI/ML Engineer & Builder of Intelligent Systems AI/ML Engineer | ChatBots, RAG & Multi-Agent systems | Simplifying LLM dev

Active 50m ago
Joined Sep 5, 2026
Powered by