Agent Platform

Iconicompany develops a platform where specialized AI agents perform work. One prepares a commercial proposal and procurement documents, another deploys clusters and analyzes errors, while development agents receive tasks and modify code. Each has its own area of responsibility, working tools, and a way to verify the result.

An agent receives a task, works with documents or systems, performs actions, and saves the result: a set of files, a configuration change, an error cause report, or a pull request. A human sets the goal and constraints, provides missing information, and makes decisions that fall outside the agent's authority.

The platform and its products are created by Iconicompany. A presentation of the product by another company at a speaking engagement or a joint event does not alter its authorship.

What tasks agents solve

Agent or component	Work area	Result
ipresale	Procurement and preparation of commercial proposals	Requirements analysis, calculation, filled forms, submission package, and a list of unresolved questions
idevops	Infrastructure and operations	Deployed clusters and applications, error diagnostics, infrastructure changes, tasks for code fixing
Development agents; direction description — icode	Development and fixes in the product repository	Code changes, checks, and the result related to the initial task
iomp based on roboomp and omp	Task reception and organization of their execution by agents	Issue analysis, a comment with conclusions, or a pull request with a fix

iomp is the execution contour for development tasks. It does not replace the domain specialization of agents. ipresale knows the procurement process, idevops knows the infrastructure; each needs its own instructions, data, and access rights.

What an agent consists of

• Work rules. The sequence of actions, requirements for the result, and stop conditions are saved in the repository. Refinement of the process must be used in the next task as well.
• Context. Procurement documents, company profile, application code, configurations, or incident details — depending on the task.
• Tools. Commands, APIs, document builders, deployment, and verification tools. Through them, the agent performs the work.
• State. What has already been done, where the result is located, which check passed, and what prevents continuation. In different processes, these are state files, tasks, and change history.
• Checks. The calculation is verified against the form, the package against the submission plan, the code change against the application behavior, and the infrastructure operation against the system state.

The model chooses actions and analyzes content. Repeatable operations are performed by tools: downloading files, calculating sums, filling cells, running checks. Therefore, a change in the model's response phrasing must not change company details or calculation arithmetic.

How work is transferred between agents

Transfer is formalized by a task with context and expected result. This allows continuing work after the session ends and seeing what the executor did.

One of the active routes is from an application error to a development task:

idevops infrastructure monitoring
  → alert-relay
  → issue in the affected product's repository
  → GitHub webhook to iomp
  → roboomp runs an agent on omp
  → cause analysis, comment, or pull request

A task is created in the product repository, and the event goes to iomp. It receives a description of the signal and details to find the cause. Repeated triggering of the same alert updates the open issue instead of creating a new task every minute. Raw log lines are not transferred to the issue: they may contain personal data and tokens.

The development agent works with the task description and the code. If it lacks diagnostic data or permissions, this limitation must be resolved; the existence of the task itself does not grant access to the infrastructure. A comment "the signal has disappeared" also does not prove that the cause is eliminated.

Another route starts with procurement: ipresale prepares requirements and materials, and when moving to development, transfers them to a separate project. The product pipeline handles further work. ipresale itself does not become the owner of the application development.

What a human gets

Upon completion of the work, the result and the grounds to consider it ready remain. For procurement, these are documents, an inventory, and check results. For application changes — code, linkage to the task, and verification of the fixed scenario. For infrastructure — the executed operation and the observed system state.

Incomplete work is explicitly indicated: missing data, a failed check, lack of access, or a required decision. A model's "done" response does not replace this information.

Where the automation boundary lies

Permissions and degree of autonomy are set for a specific agent and contour. Preparing documents does not grant the right to send an offer; a created pull request does not mean the change is already released; the ability to read code does not grant the right to change a production cluster.

A language model can make mistakes, an external service can be unavailable, or a document format or API can change. For each process, a verifiable result and a clear procedure for transferring an unresolved task to a human are needed. Quotas and limitations of the model provider can also stop execution.

Data transfer to the model must comply with permissions for that data. The platform makes no general promise that "all information always remains local": the location of the model, tools, and storages is determined by the chosen contour.

How to evaluate the result

The effect is measured by the work performed, including verification and fixes:

Direction	What to measure
Proposal preparation	Time to a verified package, volume of manual edits, missed requirements, unclosed documents
Development	Time to an accepted change, meeting task criteria, regressions, and reopenings
Operations	Time to diagnostics and recovery, repeated incidents, erroneous actions
Task transfer	Lost requests, duplicates, waiting time, tasks without a result or an assignee

Comparable tasks and identical acceptance criteria are compared. The number of agents, files, or model calls describes the system design but does not prove time savings and quality improvement.