← All projectsProject / AI workspace

AI assistant for internal applications

An internal AI workspace that connects application knowledge, user roles and controlled tool execution.

PythonFastAPIAngularPostgreSQLCeleryRedisKeycloakCodex worker
Project overview

What the service does

An employee opens the assistant inside an internal product, asks a question about that product and gets an answer based on a recorded version of its source code. When the assistant wants to use a tool, the system checks what that tool is allowed to do and may ask the user to approve it.

Knowledge about internal applications is distributed across repositories and people. A useful assistant needs the right application context and clear limits on what it may do on behalf of a user.

Who uses it

Employees who support, operate or develop internal applications; business users can use business context, while technical users can work with source-code context.

Input
  • A question and the selected application.
  • The user profile and permitted capabilities.
  • A synchronized source snapshot with its commit identifier.
Output
  • An answer, a clarification request or a request to use a tool.
  • A request the user can approve or deny before the tool runs.
  • Saved conversation history and files produced by the workflow.
System requirements
  • Business users see product information; developers can also use its source code.
  • Each repository snapshot is tied to a specific revision.
  • For long tasks, users can follow progress, answer questions and approve tool use.
  • The chat opens inside the product the user is asking about.
01 / How the service works

Employee question → product context → permission check → answer

Process mapSolid line: normal flow · dashed line: retry or return
Process map: oracleA process map showing the sequence of work, decisions and alternate routes.
INPUTEmployee questionChosen product and user profile
DATAProduct contextSource revision and code map
DECISIONAssistant decisionAnswer, ask, or request a tool
DECISIONPermission checkAllowed, denied, or approval needed
SERVICERun an approved toolScoped access and execution limits
RESULTAnswerSaved reply for the conversation
DATAConversation historyQuestion, events, answer and artifacts
STEPAsk for detailsWait for the employee’s reply
STEPRequest approvalThe employee decides before execution
RESULTAction deniedThe tool is not run
  1. INPUTEmployee question

    Chosen product and user profile

    ContinueProduct context
    new conversationConversation history
  2. DATAProduct context

    Source revision and code map

    ContinueAssistant decision
  3. DECISIONAssistant decision

    Answer, ask, or request a tool

    answerAnswer
    needs detailsAsk for details
    tool requestPermission check
  4. DECISIONPermission check

    Allowed, denied, or approval needed

    allowedRun an approved tool
    approval neededRequest approval
    deniedAction denied
  5. SERVICERun an approved tool

    Scoped access and execution limits

    tool resultAnswer
  6. RESULTAnswer

    Saved reply for the conversation

    saved replyConversation history
  7. DATAConversation history

    Question, events, answer and artifacts

  8. STEPAsk for details

    Wait for the employee’s reply

  9. STEPRequest approval

    The employee decides before execution

    approvedRun an approved tool
  10. RESULTAction denied

    The tool is not run

Arrows show the direction of work; labeled branches show decisions, errors and retries.
02 / System architecture

Main components and their roles

OIDC / app registry

Choose context

The user selects the application and the profile that matches their task.

How it works

Embedded authentication binds the principal to an application group and removes technical roles.

Git sync / commit SHA

Load knowledge

The assistant receives a versioned snapshot of the relevant repositories.

How it works

Background sync records the repository revision and builds a code map that helps the assistant find relevant files.

PostgreSQL / Celery

Record the run

The question and execution settings become a tracked task.

How it works

The scheduler does not start another run while one is active. PostgreSQL stores the current attempt and session state; Celery sends the task to a worker.

Agent worker

Plan the response

The worker can answer, request clarification or ask to use a tool.

How it works

The system checks the worker response before continuing the task. Tool use follows the selected run mode and timeout.

Capability policy

Check the action

The requested action is allowed, denied or sent for confirmation.

How it works

The policy checks the requested tool, run mode and conversation context. Access to local folders also requires browser permission for the selected folder.

SSE / sequence cursor

Follow progress

The user sees progress and can return to a disconnected session.

How it works

Agent events are stored in order. If the connection drops, the frontend continues from the last received event.

Messages / artifacts

Keep the result

The answer, context version and generated artifacts remain associated with the conversation.

How it works

The conversation keeps the assistant reply, repository revision and files created during the task.

03 / Implementation details

Engineering decisions

01

Permission before action

Tool requests pass through an explicit policy and approval state instead of executing solely on model output.

02

Versioned context

Repository revisions remain attached to the knowledge snapshot, so an answer can be related to the inspected source.

03

Resumable interaction

Persistent events and sequence cursors support continuity during long tasks and connection interruptions.

Software development for business

Have a project in mind?

Tell me what the application should do, how the team works today and which requirements or deadlines matter.