OpenAI Chat API: Build a Work Assistant With Shared Context

The OpenAI Chat API is the endpoint your code calls to get a language model response with full control over the messages, tools and instructions. A work assistant built on it can answer questions about your data, draft content from a template, or route incoming items to the right next step. Tools like fenbs supply shared project context through an MCP connection, so the assistant starts each session from the current state of the work rather than from a blank conversation.

For API keys and your first request, start with OpenAI API: build and review a small project. This page covers the message structure, tool calls and output checks that make a work assistant reliable.

How the Chat API message structure works

Every call to the Chat API sends a list of messages. Each message has a role: system, user, assistant or tool. The system message runs first and sets the model's behavior for the entire call. User messages carry the input. Assistant messages can be included to give the model context about what it said earlier in the conversation. Tool messages carry the results of any tool calls the model requested.

For a work assistant that needs to know about your project, include the relevant context in the system message or as a user message before the actual request. The model does not remember anything between calls unless you include it explicitly. This is what MCP addresses: a connected tool like fenbs provides the current project state when the session opens, so the assistant reads it as part of its context.

Add tool calls to let the assistant take actions

Tool calls extend the assistant beyond text generation. You define a function, describe what it does and what parameters it takes, and include it in the tools list. When the model decides to use the tool, it returns a structured call with the arguments. Your code then executes the function and sends the result back to the model.

from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "get_project_status",
        "description": "Get the current status of a project task.",
        "parameters": {
            "type": "object",
            "properties": {
                "task_id": {"type": "string", "description": "The task identifier."},
            },
            "required": ["task_id"],
        },
    },
}]

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a work assistant. Use get_project_status when asked about tasks."},
        {"role": "user", "content": "What is the status of task FET-014?"},
    ],
    tools=tools,
)

The model returns a tool call object when it decides to use the tool. Your code reads the arguments, executes the real function, and sends the result back in a tool message. The model then uses the result in its final response. This loop can repeat if the model needs multiple tool calls to answer one question.

Supply shared context at the start of each session

A work assistant is most useful when it knows the current state of the work: what the project is trying to achieve, what decisions have been made, and what the next task is. Without that context, it answers general questions well but project-specific ones poorly.

One way to supply context is to include a summary in the system message. A more maintainable way is to use an MCP connection to a tool like fenbs, so the assistant reads the current project context at the start of each session without you having to paste it manually. Either way, the context the assistant receives should include the relevant rules and where the work stands, not the entire history of every conversation.

Check outputs before acting on them

A work assistant that takes actions, not just produces text, needs a review step before each action. Define the review rule before you build the assistant: what outputs can be used automatically, what outputs need a person to confirm, and what outputs should be rejected entirely. Write that rule down as a project decision.

Automatic checks can cover format validation, length limits and keyword filtering. Human review is appropriate for anything that sends a message, modifies a record or commits to an external service. The boundary between automatic and human review is a decision for the people building the assistant, not one the model should make for itself.

Keep a history of what the assistant did

A work assistant that takes actions should leave a record of what it did. At a minimum, log the inputs, the tool calls made and the outputs returned. That log lets you check what the assistant did when something goes wrong, without having to reproduce the entire session.

In fenbs, every change made through a connected assistant appears in History with who made it and when. That record is not a substitute for your own application logs, but it covers the decisions the assistant recorded on the board: tasks moved, decisions logged, progress saved.

How to build this with fenbs

Start with the project context before writing the assistant code. A well-structured project record is more valuable than a well-tuned system prompt.

1. Create a free account. Start with a personal board for a solo project.
2. Add the project. Write the assistant's purpose, the tools it will use, the review rule, and the scope of work it may touch.
3. Add tasks for each piece of work: message structure, tool definitions, review logic, context loading. Move each to In Progress when you start.
4. Record your design decisions: why this tool set, what the review trigger is, how the session context is loaded.
5. Connect your AI coding assistant from Integrations. It reads the project AI context at the start of each session so it knows the rules and where the work stands.