Three recruiting days on the same campus, the International University of Casablanca (UIC), 16 to 18 September 2026. One operator role per day, six hours to build, internal scoring, a jury that watches.
Most people do not know which operator they are. Come for one day or all three; the scoring places you.
DAY 1
Client conversation to a validated prototype.
✓
16 September 2026. Business situations, six hours.
✓
Find the pain point and build something a client can react to.
✓
Versatile, creative, across industries.
✓
The Octopus block in delivery is two weeks. This day tests that muscle.
✓
Students and graduates. You can come all three days.
DAY 2
Prototype to production.
✓
17 September 2026. Take a prototype as far as it can go.
✓
Architecture, design, system thinking.
✓
Scale it so thousands of users could rely on it.
✓
The Wolf block in delivery is five weeks, the biggest one. This day tests that muscle.
✓
Students and graduates. You can come all three days.
DAY 3
Production to finished.
✓
18 September 2026. UX, edge cases, the 1-in-1000.
✓
The sharp eye. Hence the name.
✓
Fewer clicks, better data presentation, polish at every level.
✓
The Eagle block in delivery is three weeks. This day tests that muscle.
✓
Students and graduates. You can come all three days.
WATCH
Local business leaders watch how DaiL works.
✓
The jury does not pick winners. Internal scoring does.
✓
A day on the jury is how a company sees the work, without a pitch.
✓
Business leaders from Casablanca and the region.
✓
Write to contact@dail.info if you want a jury seat.
AFTER THE DAYS
Contracts after incorporation.
✓
Winners can join Casablanca AI Lab.
✓
No employment before the Moroccan entity exists.
✓
Offers wait for the incorporation certificate, expected mid-October 2026.
✓
UIC is the floor for these three days.
✓
Apply on the form, or write to contact@dail.info.
DAY 1
The full onboarding guide DaiL uses for the role. Read it before 16 September.
Move quickly from conversation to prototype. Speed creates momentum, gives the client something concrete to respond to, and exposes wrong assumptions early.
Make connections that are not obvious. Reuse DaiL components in new combinations. Look for the interaction or workflow detail that makes the solution feel designed for this client.
Make complex technology understandable and relevant. Listen closely, build confidence, and help the client see what becomes possible inside their own business.
Enter unfamiliar situations without being intimidated by new industries, systems, or terminology. Preparation helps, but an Octopus must also think clearly in the room.
Stay close to the edge of what current models and tools can do. Model capabilities improve constantly. The quality and ambition of our prototypes should improve with them.
01
Learn the business, tools, and likely pressures before the meeting. Find relevant DaiL work and configure the harness so it can take notes, retrieve similar projects, and surface questions. The aim is not to know everything. The aim is to recognize the important thing when it appears.
02
Establish credibility, then watch where the client responds. As soon as they describe use cases, stop presenting and listen: the problem, who feels it, how the process works today, which systems are involved, and what a convincing result looks like.
03
Many clients still think of AI as a chatbot that waits for a prompt. Show the difference between a pull-based assistant and a push-based agent. Explain local-first as data control, privacy, and compliance from the start, not as an afterthought.
04
With consent and approved tooling, the harness captures decisions, retrieves similar work, explains unfamiliar systems, and can produce an initial view the client can react to. It expands attention. It does not replace it.
05
Write four or five observations that require human instinct: what made their eyes widen, which bottleneck they kept returning to, who cared about control versus speed. Those notes often become the feature that makes the prototype feel exceptional.
06
Spend up to two focused hours after the meeting making the idea visible. Track the problem, users, core workflow, systems, and assumptions. Do not wait for a perfect specification. The prototype is part of discovery.
07
For the next few days, improve the prototype in focused cycles. Set a concrete outcome, review what the harness produced, test it, and define the next outcome. Keep it functional. A strong demo proves the central workflow can work.
08
Show progress every few days. Each session should answer three questions: are we solving the right problem, does this workflow fit how they operate, and what must change before this becomes a real project. Track feedback as decisions.
09
At the end of two weeks, package transcripts, the prototype, confirmed requirements, open questions, systems, scope, and risks. A strong handoff lets the Wolf take over without repeating discovery. Then review it yourself.
DAY 2
A Wolf is the operator who receives a validated prototype from an Octopus and turns it into a productive, scalable system.
The prototype was built to convince in days. The production system has to be correct under load, with real data, and maintainable by someone else afterwards.
The system sits in the client’s environment, next to their existing tools and data. The Wolf holds the whole picture, including what happens at the boundaries.
Not visual polish, which is the Eagle’s, but how the pieces are shaped and how they fit.
Getting from a working demonstration to thousands of users. This is the concrete bar the role is measured against.
Security, compliance, and every kind of user input. A production system has to survive whatever a user does to it, and stand up to a compliance question afterwards.
DAY 3
An Eagle takes the system the Wolf has built and scaled, and finishes it.
The qualifying trait. A misplaced control or an unnecessary click has to actually irritate the Eagle, because a person who can live with it will not find it.
Recognizing that a working path is still a bad path, and knowing what the shorter one is. Five clicks to two is the classic case.
Finding the one-in-a-thousand case by knowing where systems usually break, rather than by waiting for a user to report it.
Finding better ways to show and visualize what the system holds. A correct number displayed badly is still a defect.
The three days are the hiring process. The venue is UIC in Casablanca. The team is DaiL.
