HumaiX

Closed beta · by invitation

You define your company once.Every agent starts the conversation inside a frame you wrote and approved.

Firm, departments, clients. Outgoing email and calendar invites leave with your approval.

last product update · 2026-08-22

Where the frame becomes visible

The structure you define lands on a single screen in the panel: who reaches which agent, and what capabilities and services each agent carries.

  • AI Strategy Consultantno external service
  • Content ResearcherExa · Firecrawl · Gmail
  • Social Media ManagerExa
  • Email Campaign WriterGmail
  • Customer Support Botno external service
  • Sales ResearcherExa
  • SEO AnalystExa · Firecrawl
  • Meeting AssistantGoogle Calendar
  • Report GeneratorGoogle Sheets

Same information, plain text

Information embedded in a screenshot does not exist for automated readers; the list below carries the same content.

Your company, in the system

You define your firm, your departments and your clients once. When an agent starts work, what it sees comes from that frame — not from its name.

When someone on your staff talks to an agent, the agent reads from three layers: your firm's context, that person's department and that person's own memory.

firm → department → staff member

inherited on every pathFirm context

Your firm's sector, the services it offers, its language and its tone. An agent reads this before it starts work.

sectorservicestonelanguage

Limit. This profile is text you write. The system does not derive it from conversations on its own, and it is injected into no agent until it is approved.

An agent is a record

In this system an agent is not a program someone wrote for you; it is a record you open in the panel. You give it a name, write what it should do, and pick which capabilities and which services it may use. Copying an existing agent and changing it happens in the same place.

GeneralActive

SEO Analyst

Website analysis, keyword research and actionable SEO recommendations

Try the badges. Right now 2 services are connected and none of them write outward: the agent only reads. No write approval appears, but the pages it opens still pass the address gate.

6

external operations this agent can reach

0

of them behind the approval card

Technical detail

Connection code exists for fourteen external services; 85 operations in total, 26 of them behind the approval gate.

Capability and service assignment is per agent — access you grant one does not carry to another.

An agent's configuration is a row in a database; no client-specific code is written.

What ships with the installation

Nine agents come installed so you do not start from an empty page. Each is the same kind of record as the one above — one you can open, change, or switch off.

AI Strategy Consultant

Runs structured interviews with your staff and collects the findings. It has two modes — broad discovery or depth on a single scenario; the mode is set at the start of a session and does not change mid-way.

Connected services: no external service

Content Researcher

Researches a topic across the web, gathers sources and prepares a content draft.

Connected services: Exa · Firecrawl · Gmail

Social Media Manager

Prepares social media content, drawing on topic and competitor scans from web search.

Connected services: Exa

Email Campaign Writer

Writes email campaign copy and leaves the draft in your mailbox.

Connected services: Gmail

Customer Support Bot

Answers support questions and remembers past resolutions.

Connected services: no external service

Sales Researcher

Researches a company and returns it with these sections: Company Profile, Decision Makers, Pain Points, Competition, Approach Angles.

Connected services: Exa

SEO Analyst

Scans a site and produces a report with these sections: Executive Summary, Technical Issues (Critical→Low), Content Opportunities, Keyword Suggestions, Competitor Comparison, Action Items.

Connected services: Exa · Firecrawl

Meeting Assistant

Organises meeting notes with these sections: Date/Attendees/Duration, Agenda, Decisions, Actions (who–what–when), Next Meeting Suggestions.

Connected services: Google Calendar

Report Generator

Prepares a report with these sections: Executive Summary, Metrics, Findings, Recommendations, Appendix.

Connected services: Google Sheets

Someone with an administrator role does this, and you write what the agent should do as text — there is no drag-and-drop agent builder. Instruction changes are versioned, but there is no rollback in the interface today.

What this setup produces

When an agent works inside your setup, the output can take a defined shape instead of staying chat text. Two examples, and they are two different things: one is a file on disk, the other a schema-validated record in the database.

① The output carries the headings the instructions name

On the left, the relevant lines of the instruction text written at install time; on the right, the section headings of a report produced in a real session. You see the match with your own eyes.

Instructions force the shape of the output; they do not guarantee its quality — these are prompts, not deterministic templates. The text on the left is the shipped version; it is editable from the panel, so in your installation it may read differently.

Technical detail

agents.instructions is a database column; the quoted text is the installation seed.

The report is shown cropped: Executive Summary in full, Technical Issues → CRITICAL block in full, the rest cut off.

② Schema-validated output

When the agent finishes, it produces a record bound to a schema — not free text, but an output with defined fields. This is a different thing from ①: that is a file on disk, this is a record in the database.

This channel exists in four of the nine agents; in the remaining five the output is chat text and files. Even in those four it is not guaranteed: calling the tool is the model's decision on that run.

Technical detail

The schema is defined field by field: in the SEO report the target keyword list requires at least one element, and difficulty may only be low, medium or high.

The agent↔schema mapping is a code constant — you cannot give a new agent this channel from the panel; it takes a code change and a deploy.

A user can see where an agent learned something from, on their own screen → Where your data sits

Anything leaving the frame is put to you

When the agent finishes, it does not send on your behalf. It stops on screen, shows what it is about to do — to whom and with what wording — and waits for your approval. It does not truncate the text: you see exactly what you are approving.

This pause applies to the operations on that list, not to places where the agent only reads. And if nobody is at the screen, the request times out after a minute and is treated as a refusal — this product was not designed to run unattended overnight.

Technical detail

26 write operations are bound to the gate; 8 are reachable in today's installation and the rest come into play once services are assigned from the panel: sending and drafting email, creating/updating/deleting calendar events, uploading to Drive, writing to Sheets, Slack messages, HubSpot records, Notion pages, Linear issues, Mailchimp campaigns.

The gate runs INSIDE the tool's handler: what is blocked is the request to the external service, not the tool being triggered. It only runs on calls that carry a session identity.

Approval is not cached — when the same tool is called a second time, the card appears again. 60 seconds without an answer = denial.

Masking applies only to fields whose NAME contains password, token, key, secret or credential, and it looks at the field's name, not its value: a key embedded in a notes field is not masked.

The scope is a manually maintained list; a new write tool that never made it onto the list falls back to keyword heuristics alone. Read operations run without approval.

26

write operations bound to the approval gate

8

of them reachable in today's installation

The same gate for web pages the agent opens

When the agent wants to read a page, the address is checked first. It never reaches inside your company network or an address unreachable from the public internet — it does not even ask you, it refuses outright.

The gate covers tools that open pages. Web search sits outside it and is auto-approved: what you type into a search box is also information leaving the building.

Technical detail

Any scheme other than http/https, local and internal network names, and every IP unreachable on the public internet: hard refusal, the approval card is never shown.

The IP the hostname resolves to is checked as well; a name that cannot be resolved is also refused (fail-closed).

Domains and subdomains on the allow list pass without a question; every remaining external address lands on the approval card on EVERY call.

The gate resolves the hostname itself and the tool resolves it again; we do not claim protection for a DNS answer that changes in between.

Your client is inside the same setup, but not on the same screen

Your firm opens each of its clients as a separate record; people on the client side attach to that record with a separate role. An agent you assign to a client record is added to the agents that record's users can reach.

Separation between clients sits at the application layer within one installation. Physical separation is per firm, not per client.

Technical detail

Row-level PostgreSQL policies on eight tables. This layer runs only on the read paths wired to it — the agent runtime and file indexing use a high-privilege connection and bypass the policies.

The real scope is drawn by the query itself; this layer sits on top of it as a second layer, and it does not separate users WITHIN a firm.

Your client does not see the same screen as your staff: of the four tabs, Overview is never drawn for a client, and on the agent page they are routed to a simplified shell without the top menu.

That is a presentation decision, not access control. The real gate is the field filters on the server — the body that reaches a client passes a whitelist server-side, it is not hidden in the browser.

Technical detail

Profile fields opened to a client are limited to a nine-field whitelist on the server; of the provenance data only the verified flag passes.

The access decision reads the role name and does not treat an unknown role as a client (fail-closed).

Output the agent produces does not reach your client automatically. Your staff deliver the document explicitly, and what is delivered does not arrive raw — the source list, the skipped-staff count and the model label are stripped.

Delivery is opt-in at the firm→client boundary; output shared among users inside the same client record is visible without a further decision. Delivery is at the level of the client record, with no per-person restriction. Revoking a delivery deletes the row; no separate audit record is kept for the revocation.

Technical detail

Shareability is defined per output type and an unregistered type is refused (fail-closed): when a new output type is added, the question 'may a client see this' must be answered deliberately.

The visibility decision lives in a single body and all three read paths call it; there is no row that appears in a list and then refuses when clicked.

Absent from the frame on the right: the names and identifiers of interviewed staff, the skipped-staff count, the model label.

Where your data sits, where it goes

Where the frame you defined sits, and when it leaves. The heading of this section is deliberately not 'data sovereignty': every chat turn goes to a language model, and we write that in the first item.

Data that reaches the model leaves Türkiye: every chat turn goes to Anthropic; text from memory files and documents is sent to OpenAI to be turned into search vectors; connection tokens go to Nango.

What is transferred is not all of your data: it is the turn content sent to the model and the text indexed for search. The uploaded files themselves, the memory files and client profiles stay in your firm's own stack.

Technical detail

All three providers are established outside Türkiye and are named by name in the data flow note.

Every firm gets its own stack of the same versioned codebase: its own database, its own disk, its own process.

The installation pattern is per firm; the product pattern is single — no client-specific code is written. Separation is at the process, database and disk level; not at the network level.

Technical detail

Each firm gets its own Compose stack: its own PostgreSQL container, its own disk volumes, its own backend process.

The agent's access to disk is limited across three layers, and the agent cannot run shell commands on the server.

This is not real shell isolation: the capability is closed by configuration, and there is no per-session container or seccomp. If a capability that grants shell were reopened, a live audit looks for it and reports it on the health endpoint.

Technical detail

The shell capability is closed by four gates and one detector, scanned live from the health endpoint.

Every path outside the allow list is refused; with no workspace, both reads and writes fail.

The agent's route to external addresses passes through an allow list.

When the allow list is empty, no external address is auto-approved — in that state, research agents ask for approval on every page.

Technical detail

The internal-network check runs BEFORE the allow list: a listed name resolving to an internal IP cannot open the gate.

A user can see what is stored about them, on their own screen.

They see a filtered, read-only view of the memory files each reachable agent keeps about them; shared (agent-level) memory does not appear on this screen. For agents that extract structured information, the conversation each item came from is visible.

Technical detail

No editing: a change written to the file is overwritten at the next session close.

A user's data can be exported as a single file and permanently erased.

Both are administrator paths, not self-service. And erasure does not claim to be complete: fourteen items are explicitly out of scope and are returned by name in the response.

Technical detail

The export is a single JSON with 25 sections. Erasure has 30 steps and is fail-closed: if residue is found the operation is rolled back and an error is returned.

Audit records are not deleted but anonymised. Documents already delivered to a client are deliberately not deleted.

On encryption, the only thing we can say is this: the service API keys you enter and the mail password are stored encrypted.

Chat content, memory files and the files you upload sit unencrypted. We do not say 'end-to-end encrypted' or 'encrypted at rest', because it would not be true.

Technical detail

Data flow note

We have written plainly which data we send to whom. We do not claim compliance with KVKK, Türkiye's data protection law: this text has not been through legal review. It describes the data flow; it is not a legal notice.

technical evaluation

One codebase, versioned

If you are evaluating the product for your own agency, you can skip this section → What it does not do today

Nine agents, capabilities and integrations are all managed from the same admin panel. An agent's configuration is a row in a database — not code written for a specific client.

Technical detail

Python 3.11 / FastAPI / SQLAlchemy async / Alembic / Claude Agent SDK · Next.js 16 / React 19 / TypeScript · PostgreSQL with pgvector.

The context architecture has four layers (firm / department / user / client), a single injection gate ('is it approved'), and a token ceiling per layer. Limit: the profile is static text; it does not learn from conversations by itself.

Seven automated gates run on every pull request: backend tests, frontend unit tests, build and lint, i18n parity, end-to-end tests, and two dependency audits.

The gates run, but they do not block a deployment: branch protection is not in place. All seven jobs run on a single machine; we do not claim 'isolated and reproducible CI'. Test coverage is not bound to any threshold, and there is no static type checking on the backend.

Technical detail

The backend job runs against a real PostgreSQL brought up within the step, not a mock: it applies migrations first, then provisions a least-privilege database role using production's own role setup script and separately verifies that the role is NOT a superuser.

The end-to-end job brings up the whole stack from scratch; the password reset test genuinely sends mail and reads it back over REST.

Six numbers in outward-facing documents are computed from live code and compared against every occurrence in the document: migration count, SDK version, integration count, tool count, row-level security table count, router count. Active agent count and test count are OUTSIDE that scope — both are measured and written by hand.

Before every release that changes the schema, a full database copy is taken; if the copy cannot be taken, the migration never runs and the service does not start.

This guarantee can be switched off with an environment flag; while it is off, migrations run with no copy. And this is a backup specific to the moment of a release migration: routine backup is a separate operational matter and is not claimed on this page.

Technical detail

There is an explicit switch to disable it in an emergency; if there is no revision to apply, no copy is taken in the first place.

Copies from the last five runs are kept on a separate volume.

What it does not do today

We want you to know how far the frame goes today at the start of a buying process, not at the end.

Will the agent work while I am away?

No. There is no scheduler; the 26 flagged external service operations wait for approval and are dropped if unanswered within 60 seconds.

What happens if an agent gets stuck?

A stuck turn does not end by itself; there is no wall clock. The stop action releases the lock and half-written text is saved to the chat history.

Does it learn instantly as we talk?

No. Writing to persistent memory runs only at session close; in a conversation that never breaks, what is learned in that moment is not fed back into it.

Can I build my own agent from scratch?

You can open one from the panel: give it a name, write what it should do, pick its capabilities and services; copying an existing one works too. There is no drag-and-drop builder — you write what the agent does as text — and someone with an administrator role does it.

Does it read scanned PDFs, invoices, photos?

Not today. Visual reading is switched off in production; what works is plain text extraction from documents that have a text layer. The limits: 10 MB per file, 20 pages in a PDF, 100 rows per sheet in Excel.

Can I see a usage and cost report?

The data is collected, but there is no screen showing it in aggregate today — the context and quality indicator for each turn appears in the chat's status bar. On cost: there is a per-session budget ceiling at the code level, but today it cannot be adjusted from the environment in production; there is no cumulative ceiling per user, firm or month.

Can I roll back an instruction change?

Version records are written, but there is no rollback in the interface — the records are kept and reverting is done by hand today.

Can I connect the model of my choice?

No. Today, Anthropic only.

Is there an Arabic interface?

The content layer is Turkish and English. Arabic and right-to-left are not available today.

How many concurrent users does it handle?

There is a target of 50 concurrent active agent sessions in the code; this is not a hard gate — if there is no evictable session the number is exceeded and the request is not refused. Horizontal scaling is not possible today. This number is not the total user count or the total chat count.

Can I export or erase my own data myself?

Not today; export and erasure are operated by an administrator — you can view your own memory files read-only.

Closed beta: who it is for, who it is not for

Anyone can see the product; registration is closed. We prefer this process over open sign-up on the site.

Not being able to sign yourself up is not a beta restriction but a fact about the product: accounts are opened by an authorised user and activated by invitation.

Technical detail

Who it is for

  • Agencies and service firms in Türkiye and MENA with a client portfolio
  • Those who will use the product to produce work for their own clients
  • Those working in Turkish or English

Who it is not for

  • Anyone expecting unattended automation that runs overnight
  • Anyone expecting a no-code, drag-and-drop agent builder
  • Anyone expecting an Arabic interface
  • Anyone expecting scanned document reading

Each of these four is answered in full in the section above.

What happens next

We review the application and come back to arrange a conversation. If we cannot take you in this cohort we put you in the next one — that is a capacity matter, not a judgement of quality.

Apply for the beta

The application is not a commitment, it is a request for a conversation. We review it and come back to arrange one.

Technical detail

Only work email is required; the other fields are for queueing.

The free-text field stops at 300 characters — the limit is not there to deter you, it is there to say you can keep it short.