What should an Agent in an enterprise look like?

Today, Feishu released a new version of Doubao Working Partner in Beijing. You can assign an Agent to join the work group, and everyone @ it. Three months ago, Anthropic's Claude Tag did something similar on Slack.

The Pacific Ocean is separated on both sides, and the things we made look similar, but different paths were chosen in several key places.

To those who make Agents, these two products are not important in themselves. What is important is that they put a question on the table: If an Agent wants to enter a company to work with people, what should it look like?

There is currently no standard answer to this question. But there are six sub-questions that any team that is serious about doing this will have to answer sooner or later.

!

1. Is it one or a group

This is the first bifurcation in form design.

One way is to be single: you @ it, it reads the context, determines what to do, and returns to you after it is finished.

The other is choreography: after taking over the job, you break it up and send it to multiple Agents for parallel processing. You can also fix the formation and divide the work according to scheduling rules, such as one responsible for production and the other responsible for inspection.

These two designs correspond to different understandings of "what a corporate task looks like."

My judgment is that choreography will become mainstream sooner or later, because the work in an enterprise is inherently multi-role.

A plan requires people to write, review, and approve. This is not a cumbersome process, but a necessary design for decentralization of responsibilities. Letting the same context both produce and check is equivalent to letting one approve one's own solution. This is where the most common problem when automating processes is that models tend to recognize what they have just written.

But choreography raises a new question, and no one answers it now: Who cares about the choreography itself?

Who decides how many teams to form and how to divide the work? One task was divided into five sub-tasks, and the third one went wrong. Was it the captain who divided it wrong, or did the team members do it wrong? There are ready-made answers to this kind of thing in the enterprise, because the person who leads the team has to take responsibility. If it were an Agent formation, this chain would be broken.

2. Where can it touch?

The second issue is boundaries, which is more technical.

One design is to live in a collaborative platform, reading messages, writing documents, and tuning APIs, but not reaching your native computer.

The other is cloud resident and local execution: When the subject continues to run in the cloud and needs to access local files, working directories, intranet or logged in environment, the client will download it to the user's machine for execution, and the files will remain locally.

Whether or not you can touch the machine is the dividing line between "information agent" and "execution agent".

A large number of live cards in enterprises are locally: the intranet system does not have a public network interface, the business background requires a logged in browser session, and files are scattered on personal computers. If you can't reach this, all the Agent can do is organize information and draft manuscripts, but can't implement it on the ground.

But this is also where the risks are most concentrated. If something in the cloud can operate your computer, how to draw the boundary? There are currently three constraints that can be seen: within the scope of user authorization, access is restricted by rights policies, and files always remain local.

All three are necessary. Whether it is enough or not depends on the specific realization and how the enterprise allocates it. My suggestion is to make this a must-ask when purchasing, and don't wait until something goes wrong to check.

3. How proactive should it be

The third question is the most delicate.

A passive Agent is easy to do: it only moves when you shout. The difficulty is taking the initiative. It has to judge for itself when to speak and when to act.

There is a detail worth mentioning here. Claude Tag used a lightweight classifier to judge "whether this message should be returned" one by one. Later, he removed the entire classifier and changed it to let the model read the full context of the channel. Add memory and established instructions to choose one of four actions: reply directly, start work in a thread, merge into an existing workflow, orremain silent.

According to Anthropic, the change reduced unprompted speeches by about 45%.

"Keep silent" is listed as one of the four actions, and it is the most weighty design decision I have seen in both products.

The value of a thing that can speak proactively lies not in how much it can say, but in that it knows when to not say it. The figure of 45% in turn shows that the first edition was too noisy.

This is a pit that all teams that do proactive agents will step into. When I first went online, I thought,"It reminded me of the initiative, so smart." After two weeks, it became a source of noise in the group. Then everyone began to ignore it and finally moved it out of Group chats.

What determines the upper limit of initiative is human tolerance, not model ability. This upper limit is much lower than most people think.

!

4. Should the model be a replaceable part

The fourth issue reaches the planning level.

One method is to fix the model, and whoever is @ will burn it at the bottom. The administrator can control how much money it costs, but not who it will replace it.

The other is that the model is changeable. Feishu's approach is: the platform presets multiple mainstream models out of the box, and the token consumes the platform's AI quota; you can also access the API Key you have opened with the model manufacturer to replace the built-in model. At this time, the model fee is directly paid to the model manufacturer, and the platform quota is no longer consumed, but the product and tool fees are still charged according to the platform standard. The scope of support is limited to domestic mainstream models that are compatible with OpenAI interfaces and support Function Calling.

This difference exposes the two companies 'judgment on "what are their core assets."

The model is the one with all your assets and it is impossible for you to change it. The assets are the party on the job site, and there is no loss in making the model into a replaceable part, because the sentence "Products and tools are still charged according to platform standards" remains there: You are still on this platform, and your work is still done with its documents, forms, and calendars, and the output is written back to its system.

For corporate purchasers, there is an easy misjudgment. Model swapping sounds like "avoiding being locked," but thelocking point just moves from the model level to the data and workflow level. The day you replace the model, you will find that what you really can't move is the documents, forms, and processes accumulated over the past few years.

Whether this transfer is good or bad for you depends on which locking you are more afraid of. My opinion is that model locking is reversible, and data and workflow locking is basically irreversible. So the actual value of "being able to change models" is less than it sounds.

5. Control and autonomy are the same seesaw

The fifth problem cannot be avoided in product design.

The granularity of control on both sides is far different. On one side are eight categories, including agent management, model management, skill review and removal, availability range configuration, network access exit control, sensitive operation control and policy logging. On the other side of the public instructions are three: specifying which channels and tools can be accessed, setting a token spending limit, and viewing the full operation log including the originator of each task.

The difference first reflects market requirements. For domestic enterprises to purchase such systems, the control list must be reviewed. Export control, operation audit, and authority granularity are the passing lines.

But what is more worth thinking about is the cost.

The more detailed the management is, the less room the Agent has to do on his own. An Agent that requires strategic approval for every sensitive operation and an Agent that can schedule itself and independently promote projects across the sky are two products that cannot be done at the same time.

These are both ends of the same seesaw. Nowadays, few companies have seriously discussed which side they want to sit on. Most of them "follow the strictest control and then complain that the Agent is not easy to use."

6. What does it mean in the organization

The last question is the most difficult and the least asked.

Looking at the current product form, the Agent already has these things: name, scope of responsibility, permissions, cost (the management background can see consumption according to the Agent), and operation log.

Taken together, these things are almost the same as the fields of an employee record in the HR system.

It's two different.

The first is assessment. No product now can answer "How did this Agent do this month and whether it is worth the money it burned?" Cost data is available, but output data is not available. Only when this question was answered seriously did the Agent really join the organization.

The second thing is responsibility.

This has to be unfolded. You pull an Agent into a group, and it has permission to read documents, change forms, adjust business systems, and send messages to external sources. It will one day do one thing wrong: correct the wrong number, send it to the wrong person, and synchronize things that shouldn't be synchronized.

At that moment, where was the responsibility?

The answer given by both sides is essentially the same:traceability . On one side is the full operation log, which also records who initiated each task; on the other side, the operation traces are left, and permissions strictly follow the user account.

However, what can be solved retroactively is evidence collection and does not solve liability attribution.

!

What goes back to "Zhang San @ it"? There are three ways to assign responsibilities, corresponding to three completely different organizational logics:

Falling on the caller. Whoever @ is responsible. The problem is that he may have only said,"Help me sort out this month's data," and the rest is all the decision made by the Agent himself. According to this logic, in the future, everyone will consider it before @ it.

It falls on the configurator. Whoever allocates this Agent and gives it these permissions will be responsible. The problem is that it is impossible for the configurator to foresee all uses. According to this logic, the person who configures Agents in the future will be extremely conservative.

It falls on the person who approved the introduction. This is essentially treating it as a management decision, and calculating the risk of the decision if something goes wrong. This logic is closest to the company's existing system, but it means that every time authority is expanded, approval must be carried out.

I personally prefer the third of these three divisions because it can be connected to the existing responsibility system. But no matter which one you choose, you have to choose in advance and cannot wait until the first accident occurs before making a last-minute decision.

The reality is that most companies wait until something goes wrong before writing this rule. When something goes wrong for the first time, what is most likely to happen is for everyone to check the log, prove that it is not their own problem, and then stop the Agent.

QKPFX6 How will QK go in the future

First, the form will converge to "formation + local access". A single Agent cannot do multi-role tasks, and cannot do execution-type tasks if it cannot reach local ones. These two are hard requirements for corporate scenarios and have nothing to do with product preferences.

Second, the initiative will first overtake and then pull back. The first edition of all products will be made too noisy and then educated by users. That 45% is the result of a correction once, and there will be more times in the future.

Third, the competition for the interface layer will be more intense than the model layer. Models are becoming replaceable, collaboration platforms are not. Whoever occupies the work site is qualified to decide what model the Agent uses and what data it can touch.

Fourth, the liability rules will be the last piece to be added, and will be driven by the first batch of accidents, not by product documentation. This area is now a vacuum, and it is impossible for the product side to answer for the company.

Fifth, it is difficult for this set of things to grow into WeChat groups. Being able to be an "Agent as a colleague" relies on the group-connected organizational structure, documents, approvals, calendars, business systems and the authority to follow the account. WeChat groups are connected by relationships. If you put an Agent in the WeChat group, the most you can do is check the weather, send reminders, and make solitaire statistics. Enterprise WeChat is another matter, that is the same venue.

Last

Among these six problems, the first four are product and technical issues with clear solution paths, but it's just a matter of time.

The last two are organizational problems that no product can solve for you. Determining the identity, assessment, and responsibilities of an Agent must be decided by the company that uses this system.

From the perspective of product form, the technology side runs much faster than the system. By the time most companies start to seriously think about how to assign responsibilities, the Agent has probably been in the group for half a year.

few sentences boundary

The product capabilities involved in this article are subject to the statements in their respective official documents and announcements. The control section uses the chapter level of the official document, and does not expand the specific implementation of each item.

The user agreement quoted in the liability section is the main product agreement, not the special agreement for the enterprise version of the product. The actual applicable terms are subject to the version signed by the enterprise.

Both products are iterating rapidly, and their shapes and terms are subject to change at any time. The above judgment is based on the current public information and does not constitute a recommendation or evaluation to any party.