Define the need
An association wants to present an activity and help students find people to join them. The need comes before the solution.
BEHIND THE FISH · OKEIYA INTELLIGENCE
Two cofounders.
One developer.
An army of AI agents.
A human mission. An ambitious way to build.
Behind Okeiya, we are exploring a new way to build digital products: engineering briefs, specialized AI tools and decisions that remain human.
The robots are a metaphor for our AI roles and tools. They do not represent an autonomous team already in operation.
01 · MISSION BEFORE TOOLS
Why build this way?
Okeiya has two cofounders and one technical cofounder. Connecting student communities means designing a product, writing software and checking what works. Clear briefs help us use AI to move forward with these limited human resources.
AI helps move the work forward. Community gives it a purpose.
Xiao Huot
Partnerships, community and the human mission.
One developer coordinates. Two people carry the mission.
“I don’t just ask ChatGPT for code. I give it engineering briefs.”
Yannick Normand · Technical cofounder
02 · FROM NEED TO REVIEW
An idea becomes a brief. The result needs evidence.
A brief defines the need, scope, constraints, deliverables and acceptance criteria. Tools can then help design, implement and verify authorized work.
INTERACTIVE ILLUSTRATION · NO REAL EXECUTION
Explore a brief, one step at a time.
Fictional example: create an Okeiya Events feature that helps an association present an activity. Select a step to see what it contributes.
- 1. Idea
- 2. Brief
- 3. AI roles and tools
- 4. Implementation
- 5. Tests
- 6. Preview
- 7. Human review
Set the scope
Define the audience, expected behaviour, access boundaries, deliverables and acceptance criteria.
Design and break down the work
ChatGPT and working roles help examine context, propose a journey and prepare bounded tasks. Reading orchestration guidance does not launch a team.
Build within the authorized scope
Change software on an isolated branch. GitHub actions and other execution tools are separate from the read-only Okeiya Intelligence connector.
Check and correct
Run relevant checks and examine failures. A passing test establishes only what it checks. A failure calls for diagnosis or a stop.
Make the result reviewable
Prepare an isolated preview when the brief authorizes it. A preview lets people try the product; it does not mean the change is published.
Accept, revise or stop
The responsible person reviews the result and evidence. A merge or production release needs explicit approval. Useful lessons are then documented.
Explore the steps at your own pace. This illustration creates no code, activity or deployment.
03 · THE METAPHOR AND THE REALITY
Specialties, with explicit states.
A written profile, a role adopted for a brief and an operational autonomous agent are different things. Here is what our sources support.
Defined profile
Product & Design
Readable knowledge and a defined orchestration profile. Reading guidance supports reasoning; it does not prove autonomous execution.
Defined profile
Engineering
Readable knowledge and a defined orchestration profile for scoping and verifying work.
Defined profile
UX/UI
A defined specialist profile and a ChatGPT adaptation for proposing and reviewing journeys.
Working role
Frontend
A specialty used in briefs to build interfaces. No permanent autonomous agent verified.
Working role
Backend
A specialty used for services and contracts. No permanent autonomous agent verified.
Working role
Quality Assurance
A verification role: checks, scenarios and evidence review. Tests do not replace human review.
Working role
Security
A role for reviewing access and boundaries. This presentation is neither certification nor a security guarantee.
Working role
Creative Studio
A visual and editorial creation role using available tools. No permanent autonomous studio verified.
Permanent autonomous agents and verified isolation remain a vision. Existing profiles are not presented as that vision fulfilled.
04 · OKEIYA INTELLIGENCE
Agents change.
Lessons stay.
Okeiya Intelligence brings together selected product, design and engineering knowledge, plus principles and orchestration guidance. Shared context helps avoid explaining everything again for every brief.
Product & DesignEngineeringOrchestration guidance
Documents are versioned. Keeping a lesson means documenting and reviewing it; automatic learning is not claimed as active.
05 · CAPABILITY STATUS
What exists. What we are building.
A private read-only foundation
Five tools expose the overview, Product & Design, Engineering, orchestration guidance and current capabilities. This connector has no write capabilities.
A more structured working loop
Briefs, profiles and knowledge are documented. Connecting them and preserving evidence are evolving; a complete autonomous loop has not been demonstrated.
Agents adapted to each role
Agents with technically controlled scopes and verified permissions. A permanent setup for every role remains an ambition.
How are these states established?
Connector verified on October 10, 2026: ACTIVE status, read_only mode and an empty write list. The repository registry and profiles describe the roles. A configured profile does not establish that an agent is running.
This page explains our approach. It grants no access to the private founder console, private repositories or internal data.
Separate tools. Separate permissions.
ChatGPT Work
A workspace for reasoning about briefs and using available tools in an authorized session.
GitHub
Code, branches, pull requests and checks. Actions use a separate connection.
Vercel
Builds and isolated previews through separate tools, within the brief’s scope.
Supabase
Account and data services. This page and the Intelligence connector grant no general access to student data.
06 · RESPONSIBILITY REMAINS HUMAN
Humans keep the decision.
Scope before action
The brief defines permitted resources and actions. Text instructions alone do not demonstrate technical isolation.
Evidence before acceptance
Code, tests and previews must be reviewable. When a check fails, diagnose, correct or stop.
Approval before publication
Proposing, implementing, accepting and publishing are distinct steps. Merging and production require explicit authorization.
This page explains our approach. It grants no access to the private founder console, private repositories or internal data.
BUILD WITH US
Two conversations to start.
Technology companies
Let's explore collaboration around applied AI, development tooling or infrastructure. We seek practical exchanges: expertise, bounded experiments and shared learning.
We define the scope, accessible data and commitments together. This page grants no access to student data or private systems.
Discuss a collaboration →Potential investors
Let's discuss the student problem, product priorities, how we build and the evidence needed to support next steps. AI is an approach to examine, not by itself proof of a defensible advantage.
A conversation with the founders can cover needs and next steps; this page offers no investment terms or subscription.
Talk with the founders →Okeiya Consulting
Applications, portals and automations for organizations.
Explore the proposed services →University project
Drone competition
Drones facing off in an arena. Four onboard views. A giant screen to follow every strategy. Robotics meets esports.
Discover the project →